Hacker News Reader

Comment by 0xdeadb00f | Hacker News Reader

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.

View on HN

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.

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...

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.

Reply on news.ycombinator.com