You’re going to have to be more specific; what exactly do you mean by “run Linux on ARM”? Sure, I can compile Linux for ARM and put it in an app, and provided I am careful, I can bootstrap the kernel and get Linux up and running. But what do I do from here? I have Linux “running”, but it no container app around it anymore to allow interaction with iOS. (This is, of course, considering that you have gotten codesigning to work correctly and have full control over when the kernel JITs).
I mean they should have just emulated Linux on an arm processor, seeing as the hardware (Apple A-series) is already arm-based I assume that wouldn't cause as many performance issues as emulating a completely different architecture, x86.
I assume, based on the first comment in this chain - I'm not experienced with emulation of different processor architectures.
Like I said, “emulat[ing] Linux on an arm processor” is not as simple as you make it seem. To do something similar on x86, that is, run Linux on your Intel processor, you need virtualization software that acts as a hypervisor. iOS devices do not provide the capabilities to write software like this, so doing any sort of emulation in this way would not really work.
I believe what the OP is trying to say is, what if this weren't an x86 emulator, but rather just a shim which allows ARM native assembly code to be being run in the context of iOS, only with traps that allow access to a kind of HAL within the context of the App .. meaning that instead of loading up an x86 image containing the Linux kernel and user space, it'd load an ARM-based Linux kernel and does the trapping required to give a native runtime experience .. underneath the iOS layers.
That would be quite feasible and not at all impossible. And given that the original author of this amazing project has the balls required to pull off a JIT-type scheme to do x86-ARM translations, quite probably within their reach.
I don't think it's possible to do something like on iOS, because you can't write to executable pages (IIRC making a page executable requires the "dynamic_codesign" entitlement, which some Apple apps have).
dynamic-codesigning gates MAP_JIT, which is what MobileSafari uses for achieving just in time execution for JavaScript. However, you can still have a “poor man’s” JIT by marking a page as RW, sticking code in there, then marking it as RX, which does not require dynamic-codesigning and can be done by apps not made by Apple.
I think you still need dynamic codesign for this, if I try to do it my app gets killed with "Exception Type: EXC_BAD_ACCESS (SIGKILL - CODESIGNING)", unless it's attached to the debugger. I remember having this issue since at least iOS 6 or 7.
The way iSH works around this limitation with gadgets is very interesting.
Bingo. You need the get-task-allow entitlement (which Xcode will automatically inject in your debug builds, but will not allow you to submit to the App Store with), and have had ptrace called on you–either through the debugger, or if you ptrace yourself with PTRACE_TRACEME.
I have an enterprise account, so could I build my own "emulator" that actually just passes through ARM instructions using this work around ^ and then the only thing I have to emulate is syscalls and io?
There would need to be some sort of emulation later in place at some point, because traps into the kernel would need to be intercepted by the application and this just isn’t possible (at least, to my knowledge) in any application that just straight up runs unmodified native binaries. So it really doesn’t matter whether the author emulates x86 or ARM because there’ll be a performance hit either way.
