How would you suggest that they go about doing this?

Port qemu-arm to iOS and run it in syscall emulation mode. You’d then need to implement translations for all the Linux system calls. This would make it quite similar to Windows Subsystem for Linux.

No way Apple will let you put that on the App Store though!

qemu relies on being able to JIT compile, which isn't allowed in the sandbox.

You can JIT compile in the sandbox with certain entitlements that Apple is happy to grant you, as long as you don’t try to put your binary on the App Store.

Care to show how to do this or even an example of this being done?

Extraordinary claims require proof.

Sure. If you have an Xcode and an iOS device on hand, make a new project and cast “\x00\x00\x80\x52\xc0\x03\x5f\xd6” (or your own assembly) to an int (*)(), and check to see if the return value is 42 in the debugger.

That’s not getting the JIT entitlement as your prior comment claimed. ;)

It is, the entitlement is called “get-task-allow” and is usually used for saying that it’s ok to be attached to in the debugger, but serves a useful double life in making it possible to JIT. Xcode injects this entitlement for you when you create a debug build.

But it only works when debugger is attached I thought (which isn’t a practical work around).

Nope, all you need to do is call ptrace: https://news.ycombinator.com/item?id=18431524

How?

Shouldn't they just run Linux on arm? Seeing as Linux already supports it?

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.

> unless it's attached to the debugger

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?

Sure, as long as you don't try to publish to the App Store.

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.

This is the kind of thing that Apple would need to build into their processors to make iOS coding more 'free' without compromising security, right?

I think Apple's processors support virtualization already. I'm not sure, though.

Probably they need 'more' though or why would they be so particular about user binaries and so on? Great work anyway from your side. It works well...