5 ms·

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

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 :(.
      - saagarjha 8y ago
        I maintain that I mostly understand what is going on here, but I'll concede the point that my explanations are confusing and/or not directly to-the-point. You're much better at explaining things than I am ;) > 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 I had considered a very sketchy solution for this for a personal project (from the App Store's perspective) of what would be the equivalent of hacking the package manager to only install my packages which I sign beforehand with my certificate, which kinda allows installing arbitrary things to the extent of "what I have decided to compile and sign". > 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. There are two "signing" issues here which really are the same but I've separated out because I felt it to be appropriate, though in reality the second shouldn't occur: one is loading unsigned, arbitrary code from say a package you just downloaded, and one is modifying the execution of the program to emulate syscalls. If you somehow got iOS to load and execute your unmodified unsigned ELF executable, then you'd have to emulate system calls in some way, which I suggested you could do by performing the modifications you'd normally perform before even signing the binary at runtime by manually patching syscalls in executable memory (which requires JIT).

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 :(.
    - saagarjha 8y ago
      I maintain that I mostly understand what is going on here, but I'll concede the point that my explanations are confusing and/or not directly to-the-point. You're much better at explaining things than I am ;) > 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 I had considered a very sketchy solution for this for a personal project (from the App Store's perspective) of what would be the equivalent of hacking the package manager to only install my packages which I sign beforehand with my certificate, which kinda allows installing arbitrary things to the extent of "what I have decided to compile and sign". > 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. There are two "signing" issues here which really are the same but I've separated out because I felt it to be appropriate, though in reality the second shouldn't occur: one is loading unsigned, arbitrary code from say a package you just downloaded, and one is modifying the execution of the program to emulate syscalls. If you somehow got iOS to load and execute your unmodified unsigned ELF executable, then you'd have to emulate system calls in some way, which I suggested you could do by performing the modifications you'd normally perform before even signing the binary at runtime by manually patching syscalls in executable memory (which requires JIT).