3 ms·

We should be clear here that "JIT"/VM vs sandboxed code are two different considerations. Regardless of how your code is interpreted/compiled/run, you still are

We should be clear here that "JIT"/VM vs sandboxed code are two different considerations. Regardless of how your code is interpreted/compiled/run, you still are operating within the app sandbox. So most arguments about safety etc are fairly useless. The only "valid" line of argument is more in the UX space. Apple isn't able to vet the userflows in the same way if you do a post-release update. And to be clear when I say a handrolled VM, I mean that the VM knows how to interpret dynamic things into native things. This is a lot more powerful in Objective-C since it uses message passing anyways so you could theoretically build a full app in some JSON payload. So sure your native code is static, but thats because its just 1 function called 'eval'. This is still possible in Swift but requires more explicitness since it doesn't have the same dynamicism built in. It doesn't have to be entire apps that are custom though. Most app devs use it for things like customer-editable content. Think of things like the ability to update home screen layouts, or tab layouts/behavior. Depending on how much baked-in customization you build this can be extremely robust.

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.

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.