3 ms·
Preventing the execution of locally generated native code is a significant part of the iOS sandbox. It allows Apple to statically analysis binaries uploaded to
by avianlyric 4y ago
Preventing the execution of locally generated native code is a significant part of the iOS sandbox. It allows Apple to statically analysis binaries uploaded to the App Store and potential detect and prevent malicious instructions. Then they just need to harden the OS APIs, safe in the knowledge that you an app can’t execute arbitrary CPU instructions, and potentially escape kernel control. Allowing a JITed web browser on iOS means handing over the right mark arbitrary lumps of memory as executable, which substantially increases the available attack surface.
Having said that, I strongly suspect concerns around arbitrary code escaping kernel control only applies to older iPhone running substantially less sophisticated SoC than you find in a modern iPhone. Certainly any Apple SoC during the M1 era, and a good few generations before, have all the modern accoutrements needed to allow arbitrary code execution, while ensuring the kernel can always intercede and halt execution or block dangerous calls. If they didn’t have these abilities, then there’s no way an M1 Mac could efficiently run a VM, or be considered a secure platform by modern standards.