[saagarjha]

We’ll see how the shipping ARM Macs are “fused” when they come out, but my guess is that they will be more locked down than these devices: their OS will be more permissive but you will not have meaningful kernel debugging.

> Nobody can/should be able to write an that'll get through App Store checks if they asked for PLZ_NO_SANDBOX_ILL_BE_GOOD or something (at least, that's what I thought before the whole Snapchat system call thing happened).

Snapchat (on iOS at least) is still subject to the app sandbox, no app has on iOS has been granted an exception there to my knowledge. On macOS there are apps that are “grandfathered in” to not require the sandbox on the App Store, but new apps are supposed to have it. Due to the way the dynamic linker works, until recently it was possible to upload an app that could bypass the sandbox, but Apple has said they have fixed this. Some apps do have an exception to this as well, as the broad way they fixed one of the issues broke legitimate functionality in library loading. You can find those hardcoded in AMFI.kext, theoretically they could turn off the sandbox for themselves if they wanted.

[xenadu02]

The KDK has instructions for loading your own kernel extensions on Apple Silicon. This includes making a new writable root snapshot, modifying it, then blessing it for boot. It also includes kernel debugging.

Booting custom kernels is not supported at the moment but as has been noted "the Mac remains the Mac" and booting a custom kernel is allowed on the Mac.

And of course you can disable SIP.

Developer and hobbyist scenarios are an explicitly supported workflow on the Mac. Default security policies need to be the right thing for the vast majority of users but that doesn't mean anyone wants to take away your ability to do all kinds of interesting things to the system.

[saagarjha]

Yeah, I know, I read those instructions in full ;) I do have to admit that I am pleasantly surprised at how much is made accessible, I was fully prepared for this to be an opportunity to enforce mandatory codesigning, removing the ability to disable SIP or load code into the kernel, turn off secure boot, etc. but so far pretty much everything seems to be technically possible, which is nice.

However, I do still stand by my complaint; neither of us can go into too much detail of course but I think you understand that taking chips that were made to run iOS and with hardware-backed guarantees of certain properties for integrity on consumer systems makes for a poor experience when trying to do things like debug and patch the kernel. I mean, is it theoretically possible to debug the kernel? Yes, because they have been enabled superficially, but the experience of using them is much worse than you’d get on Intel (and not to mention developer-fused hardware). Personally I was only able to get it to work partially, and suspect it is even more broken/limited than how the KDK says it is; here is what I’m talking about: https://developer.apple.com/forums/thread/653319. If you aren’t aware, it took almost three weeks before someone could get a “hello world” up, so there is a real drag associated with this.

Again, I’m happy and pleasantly surprised to have these things, at least on macOS; it’s completely possible that these are just unintentional bugs or transitional issues or whatever, if they end up fixed I promise I will stop complaining about this particular thing. But I would like to emphasize that I do not consider the current state of affairs as laid out by the KDK to really count, regardless of the effort being put into this to make it work, which I fully understand helps back up the claim that “the Mac remains the Mac”.

[mrpippy]

> you will not have meaningful kernel debugging

Given that kext development is still supported (although highly discouraged), won’t they have to support the same level of kernel debugging as usual?

> On macOS there are apps that are “grandfathered in” to not require the sandbox on the App Store

Can you name any of these apps? Apple’s own apps don’t have to be sandboxed (like Xcode or macOS installers), but I don’t know of anything else that gets an exception. Some apps like Office get special “holes” out of the sandbox (in the form of additional SBPL), but fundamentally they’re still sandboxed.

[saagarjha]

> Given that kext development is still supported (although highly discouraged), won’t they have to support the same level of kernel debugging as usual?

They just need to support loading kernel extensions. As watchOS has shown, developers will figure out a way to get their thing working on your device even if your make debugging extremely painful. (Apple's current silicon prevents debugging entirely because the kernel is prevented from being patched in hardware.)

> Can you name any of these apps?

Sure. If your app's bundle ID matches one of

  com.aspyr.civ6.appstore
  com.aspyr.civ6.appstore.Civ6MetalExe
  com.aspyr.civ6.appstore.Civ6Exe
  com.tencent.WeWorkMac
  com.tencent.WeWork-Helper
  com.igeekinc.DriveGenius3LEJ
  com.igeekinc.DriveGenius3LEJ.DriveGenius
  com.igeekinc.DriveGenius3LEJ.dgdefrag
  com.igeekinc.DriveGenius3LEJ.dgse
  com.igeekinc.DriveGenius3LEJ.dgprobe
  com.prosofteng.DGLEAgent
  com.prosofteng.DriveGeniusLE
  com.prosofteng.DriveGenius.Locum
  com.prosofteng.DriveGenius.Duplicate
  com.prosofteng.DriveGenius.Benchtest
  com.prosofteng.DriveGenius.FSTools
  com.prosofteng.DriveGenius.Scan
  com.prosofteng.DriveGenius.Probe
  com.prosofteng.DriveGenius.SecureErase
  com.prosofteng.DriveGenius.Defrag

dyld interposing is enabled for your app even if it comes from the App Store, opening the door for subverting the mechanism for applying the sandbox.

[Wowfunhappy]

Huh, I wonder why those got exceptions. You said they were "Grandfathered in", but Civ 6 at least is recent.

[saagarjha]

They're two separate groups. Group one, the grandfathered one, is "legitimate" software that was simply published to the store prior to the mandatory sandboxing requirement–those can still get updates and remain unsandboxed. The second group is the list that I posted here, that have special status in the dynamic linker (can interpose functions) and through that can (probably don't, but "can" on a technical level by exploiting flaws in how Apple does sandboxing) bypass the sandbox.

[GekkePrutser]

> We’ll see how the shipping ARM Macs are “fused” when they come out, but my guess is that they will be more locked down than these devices: their OS will be more permissive but you will not have meaningful kernel debugging.

My big worry is them dropping terminal access altogether like on iOS. That would really make the platform useless to me.

However I don't think they would do this at this point. There's many user groups (like cloud developers) specifically favouring Mac because of the strong terminal access.

[easton]

Craig specifically said that this wasn't going to happen, in one of the podcasts he said people came up to him internally and said "Wait. There's still Terminal, right?" and he said "Yeah, it's a Mac.". The Platforms State of the Union host also said that they had made contact with a bunch of open-source projects with assistance (and in some cases, iirc the OpenJDK and CPython, pull requests) on moving to ARM.

[GekkePrutser]

Thanks, I didn't know that. Good to hear!

[john_alan]

Yep. And Craig also said the Mac is staying open. And that he was sick of trying to convince people that!

[saagarjha]

There will be a terminal, and virtual machines, and kernel extensions. It's pretty much a "full" macOS experience to all but the most serious users.

[john_alan]

What’s missing?

[saagarjha]

Well, we don't know entirely yet. But based on the videos and what we know about DTK, patching the kernel is no longer something you can do for example. That's enforced in the silicon itself almost immediately after the computer comes out of reset, so even with arbitrary code injection into the kernel (extensions) you're not getting around it.