4 ms·

Why run x86 Linux binaries? Wouldn’t it be easier and more efficient to run ARM binaries? Then you’d only need syscall translation, no? I guess you would also

Why run x86 Linux binaries? Wouldn’t it be easier and more efficient to run ARM binaries? Then you’d only need syscall translation, no? I guess you would also need a thuniking layer to handle binary format/ABI differences. But that would still be better in terms of time and space than emulation I would think.

saagarjha 8y ago
See discussion from earlier today as to why this wouldn't really help: https://news.ycombinator.com/item?id=18425906 https://news.ycombinator.com/item?id=18425906
- monocasa 8y ago
  I'm still not convinced. Even something like early VMware that scanned for the gnarly pieces that break Popek&Goldberg but just passes through most instructions should be better. In this case probably just syscall, some crazy system register reads that might return different things (but there aren't many of those in AArch64 EL0), and enough thunks that code can pretend it's executing at it's original location. Hell, equally sized RISC instructions should mean you can more quickly scan code than VMWare had to put up with doing crazy CISC decode just find out if they need to translate an instruction or not.
  - headmelted 8y ago
    Likewise. Obviously it's not as simple as in Android where you're already inside a Linux shell under the covers, but there's no technical requirement I've read here that should mandate emulation. Aside from the above, the syscall layer alone would be much more useful than bundling emulation into the picture that we know is going to perform poorly. An aarch64 Linux rootfs on the A12x would have me throwing my money at one right now.
    - saagarjha 8y ago
      > there's no technical requirement I've read here that should mandate emulation I mean, what's wrong with the requirements that I mentioned? It's fundamentally impossible to run these binaries unaltered and still hook syscalls, which means that emulation is required.
      - headmelted 8y ago
        You're confidence about this makes me not doubt that you're correct, but the linked thread doesn't really discuss this in enough detail that it's clear that running a native sandbox is not possible. I'm not really experienced with iOS' underlying architecture, so I'll happily take your word for it - it's just that the linked thread mentions that virtualization is possible but not but sort of.
        saagarjha 8y ago
        The fundamental argument is that you will need emulation at some point because every syscall needs to be hooked, so you need to be able to stop before a system call is executed and respond appropriately. If you are running native code, you'd need to change the binary at runtime to do something else instead of the syscall, which means you're essentially writing to executable memory.
        saurik 8y ago
        The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed. If you were going to limit this app to the code that was shipped with the app you could also just replace the syscall instructions as part of the same pass that signed the binaries. Even if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator. You are coming to mostly correct conclusions here, but frankly all of your explanations for this are confusing and most of them are incorrect :(.
        8y ago
  - saurik 8y ago
    You can't do the thing you are suggesting because that would require being able to take those instructions that are being "passed through" and run them, which would require marking them executable. What you would effectively end up having to do is write an emulator for ARM, at which point you haven't gained anything. Choosing x86 was a really sane choice given how many existing tools and packages are available for x86 (though ARM is, of course, becoming more popular and accessible).
    - krackers 8y ago
      >because that would require being able to take those instructions that are being "passed through" and run them Isn't this just a matter of writing it to some page and then setting the RX bit?
      - saagarjha 8y ago
        > Isn't this just a matter of writing it to some page and then setting the RX bit? Yes, but this is not easy to do on iOS: you need certain entitlements to perform this operation.
      - saurik 8y ago
        The ability to mark a page executable would defeat Apple's codesign feature, so a normal developer definitely can't do that.
        outadoc 8y ago
        It's basically the easiest way of treating data as instructions, sort of like executing a compiled program as you would with an interpreted language?
- qalmakka 8y ago
  So it's mainly an iOS limitation? I don't understand why it shouldn't be possible to take the same route software like WINE or WSL have taken before on a less constrained OS like macOS.
  - saagarjha 8y ago
    Yes, this is mostly an iOS limitation rather than a hardware one. There are many ways to make something like this work if iOS allowed things like forking processes or JIT (for App Store apps)–actually if this was possible, the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.
    - lloeki 8y ago
      > the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do. Or jailbroken iOS for that matter (at least when I last did a jailbreak which was quite some years ago, I honestly don't know about the current situation)
      - nathan_f77 8y ago
        I kind of miss being able to SSH into my iPhone and run scripts, or just poke around the filesystem. It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. That was about 8 years ago. I might do that again sometime. It's not urgent though, and I wouldn't switch to Android just for that. But I keep an eye on the jailbreak community. I also really like the idea of having a portable keyboard and screen to turn my phone into a little development machine. I think the CPU is actually more powerful than my old 2012 MacBook, although it doesn't have as much RAM.
        jsjohnst 8y ago
        > It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. There’s a number of apps on the App Store already that allow exactly this. Two of my personal favorites are Blink and Termius (use them both, but for different reasons).
copperx 8y ago
To prove that it's easier to make binaries run in another OS altogether than in another Linux distribution. That would be my guess.
- jarfil 8y ago
  Docker does that (and so do LXC, Flatpak, Snap, etc).
ant6n 8y ago
I wonder to what extend it's possible to include every executable from the standard apt-get ARM repository (but not any other resources) in the app. Since the code is included at compile time and bundled with the App, Apple should allow it. Then one could add some sort of apt-get shim that fetches the non-code resources and installs them; and something to catch system calls (which could maybe be overridden at compile time as well).
- saagarjha 8y ago
  This is Alpine Linux, so there's no apt-get ;)
- qalmakka 8y ago
  "standard apt-get repository" is wrong in so many ways that I don't really know where to start correcting it.
- saurik 8y ago
  FWIW, without nitpicking your language (as it is clear what you are saying, and the question is a totally legitimate one), the answer is "yes: that would absolutely be possible".
  - ant6n 8y ago
    Not if the resulting executable is on the order of tens of gigabytes in size, or if the executables use features that aren't available/allowed in iOS (like runtime code generation and execution).

saagarjha 8y ago

See discussion from earlier today as to why this wouldn't really help: https://news.ycombinator.com/item?id=18425906 https://news.ycombinator.com/item?id=18425906

monocasa 8y ago
I'm still not convinced. Even something like early VMware that scanned for the gnarly pieces that break Popek&Goldberg but just passes through most instructions should be better. In this case probably just syscall, some crazy system register reads that might return different things (but there aren't many of those in AArch64 EL0), and enough thunks that code can pretend it's executing at it's original location. Hell, equally sized RISC instructions should mean you can more quickly scan code than VMWare had to put up with doing crazy CISC decode just find out if they need to translate an instruction or not.
- headmelted 8y ago
  Likewise. Obviously it's not as simple as in Android where you're already inside a Linux shell under the covers, but there's no technical requirement I've read here that should mandate emulation. Aside from the above, the syscall layer alone would be much more useful than bundling emulation into the picture that we know is going to perform poorly. An aarch64 Linux rootfs on the A12x would have me throwing my money at one right now.
  - saagarjha 8y ago
    > there's no technical requirement I've read here that should mandate emulation I mean, what's wrong with the requirements that I mentioned? It's fundamentally impossible to run these binaries unaltered and still hook syscalls, which means that emulation is required.
    - headmelted 8y ago
      You're confidence about this makes me not doubt that you're correct, but the linked thread doesn't really discuss this in enough detail that it's clear that running a native sandbox is not possible. I'm not really experienced with iOS' underlying architecture, so I'll happily take your word for it - it's just that the linked thread mentions that virtualization is possible but not but sort of.
      - saagarjha 8y ago
        The fundamental argument is that you will need emulation at some point because every syscall needs to be hooked, so you need to be able to stop before a system call is executed and respond appropriately. If you are running native code, you'd need to change the binary at runtime to do something else instead of the syscall, which means you're essentially writing to executable memory.
        saurik 8y ago
        The reason you need emulation is not to hook the syscall instructions, even if that is sort of in the same general area as true: it is because the code for these binaries is not shipped with the app and signed. If you were going to limit this app to the code that was shipped with the app you could also just replace the syscall instructions as part of the same pass that signed the binaries. Even if you didn't need to hook the syscall instructions, it is the lack of code signature on these files that is requiring the emulator. You are coming to mostly correct conclusions here, but frankly all of your explanations for this are confusing and most of them are incorrect :(.
        8y ago
- saurik 8y ago
  You can't do the thing you are suggesting because that would require being able to take those instructions that are being "passed through" and run them, which would require marking them executable. What you would effectively end up having to do is write an emulator for ARM, at which point you haven't gained anything. Choosing x86 was a really sane choice given how many existing tools and packages are available for x86 (though ARM is, of course, becoming more popular and accessible).
  - krackers 8y ago
    >because that would require being able to take those instructions that are being "passed through" and run them Isn't this just a matter of writing it to some page and then setting the RX bit?
    - saagarjha 8y ago
      > Isn't this just a matter of writing it to some page and then setting the RX bit? Yes, but this is not easy to do on iOS: you need certain entitlements to perform this operation.
    - saurik 8y ago
      The ability to mark a page executable would defeat Apple's codesign feature, so a normal developer definitely can't do that.
      - outadoc 8y ago
        It's basically the easiest way of treating data as instructions, sort of like executing a compiled program as you would with an interpreted language?
qalmakka 8y ago
So it's mainly an iOS limitation? I don't understand why it shouldn't be possible to take the same route software like WINE or WSL have taken before on a less constrained OS like macOS.
- saagarjha 8y ago
  Yes, this is mostly an iOS limitation rather than a hardware one. There are many ways to make something like this work if iOS allowed things like forking processes or JIT (for App Store apps)–actually if this was possible, the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do.
  - lloeki 8y ago
    > the project at that point would probably just be "spawn a shell" instead of "emulate x86 and bootstrap a whole Alpine Linux install", since this is what most terminal emulators on Android do. Or jailbroken iOS for that matter (at least when I last did a jailbreak which was quite some years ago, I honestly don't know about the current situation)
    - nathan_f77 8y ago
      I kind of miss being able to SSH into my iPhone and run scripts, or just poke around the filesystem. It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. That was about 8 years ago. I might do that again sometime. It's not urgent though, and I wouldn't switch to Android just for that. But I keep an eye on the jailbreak community. I also really like the idea of having a portable keyboard and screen to turn my phone into a little development machine. I think the CPU is actually more powerful than my old 2012 MacBook, although it doesn't have as much RAM.
      - jsjohnst 8y ago
        > It was fun to have a terminal app and editor where I could edit some code, and then deploy changes to a server. There’s a number of apps on the App Store already that allow exactly this. Two of my personal favorites are Blink and Termius (use them both, but for different reasons).

copperx 8y ago

To prove that it's easier to make binaries run in another OS altogether than in another Linux distribution. That would be my guess.

jarfil 8y ago
Docker does that (and so do LXC, Flatpak, Snap, etc).

ant6n 8y ago

I wonder to what extend it's possible to include every executable from the standard apt-get ARM repository (but not any other resources) in the app. Since the code is included at compile time and bundled with the App, Apple should allow it. Then one could add some sort of apt-get shim that fetches the non-code resources and installs them; and something to catch system calls (which could maybe be overridden at compile time as well).

saagarjha 8y ago
This is Alpine Linux, so there's no apt-get ;)
qalmakka 8y ago
"standard apt-get repository" is wrong in so many ways that I don't really know where to start correcting it.
saurik 8y ago
FWIW, without nitpicking your language (as it is clear what you are saying, and the question is a totally legitimate one), the answer is "yes: that would absolutely be possible".
- ant6n 8y ago
  Not if the resulting executable is on the order of tens of gigabytes in size, or if the executables use features that aren't available/allowed in iOS (like runtime code generation and execution).