Hacker News Reader

Comment by lazerl0rd | Hacker News Reader

Thanks for the amazing work, I thought about this a while back when I saw WINE Hangover for Android but this is even better (in some ways, at least). Sadly, the iPadOS/iOS 13.3.1 issue is a headache and the certain jailbreak tools which usually get around IPA signing aren't working either.

Whilst most people are saying it's a bug on Apple's side I'm worried it's more than that. The removal of signed iPadOS/iOS 13.3 from their servers, along with the returned ability of flashing static lib'ed packages after all being blocked for a while seems more "on purpose" from Apple rather than "by accident". We gotta just wait and see, I guess.

View on HN

I think the jailbreak IPA signing isn’t working because it needs the `get-task-allow` entitlement which idk if every tool is aware of. This entitlement is only given out in development profiles and not any distribution profiles so I can’t upload to TestFlight either. If Apple locks down what you can do with `get-task-allow` in the future then a jailbreak would be required to run this.

Would you by any chance consider TestFlight to distribute UTM? iSH (a usermode Linux "terminal" emulator) has been for quite some time, and I can't see why you shouldn't be able to.

> This entitlement is only given out in development profiles and not any distribution profiles so I can’t upload to TestFlight either.

Ah sorry, my bad, I skipped over that. Here's an idea - you could start a "fundraising" of sorts and if you get enough you could purchase a developer profile to publish to TestFlight.

You can’t purchase such a profile. Apple doesn’t ever give them out.

I thought this would be part of their $99/year subscription, well that's unfortunate. Thanks again for your project.

The problem here is not that they can't obtain a development certificate. The problem is that you cannot use a development certificate to distribute an app on TestFlight or the App Store to other people.

There are two types of certificate – development certificates, which allow get-task-allow for debugging purposes and can be installed directly to a device; and distribution certificates, which do not allow get-task-allow and can be distributed through ad-hoc means, Test Flight, or the App Store.

If this app requires get-task-allow, then it needs to be signed with a development certificate to run. If it's signed with a development certificate, then it can't be distributed to other people.

iSH works differently. It’s not running “Linux” and it isn’t virtualizing hardware either. Anything you run has to be compiled already and the syscalls are emulated, there is no Linux kernel in iSH.

I said it was a 'usermode Linux "terminal" emulator', never said it was a VM or anything like that. IIRC the dev said he also wasn't allowed to publish it to the App Store and I assume it falls under the same catagory of "not allowed" in Apple's eyes as UTM would've had.

> I said it was a 'usermode Linux "terminal" emulator', never said it was a VM or anything like that.

It's a full x86 emulator.

> IIRC the dev said he also wasn't allowed to publish it to the App Store

He didn't, it's just never been tested whether it could be on the store or not.

Actually, someone compiled it, added ads, and put it on the App Store. Not sure if it is still there, but it got through approval.

Oh, that happens all the time. The real test is when the official app gets approved and stays on the App Store.

iSH actually uses a semi-JIT to emulate an x86 CPU — it doesn't run ARM64 code. It basically creates an arrray of function pointers to snippets of pre-translated code. It's not a full JIT like UTM, but it's an interesting workaround for iOS' restrictions.

Official description: https://github.com/tbodt/ish#a-note-on-the-jit

A more accurate term for it would be threaded interpretation.

> Anything you run has to be compiled already

You can compile binaries on iSH and they'll run on the emulator just as all the other code does.

Compile using what? It’s form of emulation has never been complete enough to run a compiler (heck even interpreters like Python have been very brittle) in my experience as a user since the beginning, so I’m curious what you’ve seen success with.

GCC works reasonably well.

Interesting, thx for the reply. I haven’t tried GCC in the last few updates, so will try again.

Edit: just tried it and indeed you are right, it works in a few cases now. Clang also works for basic test cases.

Curious what you use that for. My previous exposure for "get task" on Darwin/XNU is it's useful for reading or writing the memory of another process and suspending or resuming its threads, as in writing a debugger.

The app pretends to debug itself, which tricks the kernel into allowing it to flip the permissions of pages between write and execute. To do this it needs the get_task_allow entitlement.

Ah ok. So everything with a JIT will need this. I think I might even have read that somewhere long ago.

This is a weird thing by the way. It seems to me like you should be able to debug or do VM syscalls against yourself because there is no escalation of privilege. Debugging another process makes much more sense to block. But maybe my opinion is invalid because I also happen to think disallowing jit with kernel permissions is very silly. (Maybe dropping ability to do this in the style of openbsd's pledge(2) would be appropriate, but only for a process that really wants extra security.)

> So everything with a JIT will need this.

Actual JITs (ones blessed by Apple, not hacks like these) possess the dynamic-codesigning entitlement, and can just make RWX pages.

> But maybe my opinion is invalid because I also happen to think disallowing jit with kernel permissions is very silly.

Your opinion isn't invalid, but it goes against Apple's security model of iOS (namely: apps should not be able to modify themselves).

> Your opinion isn't invalid, but it goes against Apple's security model of iOS (namely: apps should not be able to modify themselves).

And my position is this is a silly approach, or, maybe is ok but should be opt-in, or perhaps opt-out with third parties being automatically trusted to decide they want to use JIT without hoops.

W^X is good default policy but Apple's policy is unreasonable and paranoid.

I can’t remember weather it was ish or some JS thing but you can do a kind of JIT without RWX by setting up chains of functions that tailcall eachother.

iSH has a threaded interpreter that works like that, yes.

Reply on news.ycombinator.com