|
|
|
|
|
by apatheticonion
811 days ago
|
|
I'm not an expert in emulation but I am curious if one could recompile ROMs AOT such that JIT is not required by the emulator? Say, statically recompile the ROM on your PC then move the emulator-specific binary to the iOS device. Would such an approach be permissible by Apple? Is it possible to do so while sharing the source code for the JIT layer? I suppose the binary format must itself be natively compatible by iOS otherwise you'd need to have a JIT layer for your binary format - right? |
|
JIT compilers are one of few use cases where an application absolutely needs the ability to write data to memory, mark that memory region as executable, and then execute the op codes in that memory region. On iOS, other than Safari, no application, either built in or installed via the App Store is allowed to change memory permissions from writable to executable, and that acts as a cornerstone in iOS application sandboxing.
Now there’s perfectly good argument that the security argument doesn’t really stack up anymore, given that sandboxing technologies have progressed a lot, and it should be possible to properly sandbox a JIT compiler or similar. But there’s no denying the fact that removing the ability for an application to execute arbitrary created op codes is a very good way to completely eradication a huge surface area for exploits. Especially when such restrictions are paired with static scanning of binaries before signing (which happens when any binary is produced for iOS, via Apples signing service).
All of that is to say, there is a possible world where ROM are transpiled for iOS devices (using something like Rosetta), and loaded as signed binaries via emulation wrappers. But at point you’re basically having to create your own App Store, and sign a new app for each transpiled ROM.
In short, it doesn’t seem likely we’ll see JIT powered emulators on iOS anytime soon, and, at least in this specific instance, Apple has a legitimate security reason for restricting their usage.