Hacker News Reader

Comment by saagarjha | Hacker News Reader

> One possible downside of the new Macs, is that Apple keeps talking about the new secure boot feature only allowing Apple signed operating systems to boot as a security feature. Does this mean we won’t be able to run Linux on these new Macs, except using virtualization?

No, you can turn off secure boot.

View on HN

Was it just a gaffe when Federighi mentioned you couldn't install alternative operating systems in his recent Daring Fireball interview, then? I admit I could have misunderstood him, but it seemed like that was what he was saying.

Did he say you couldn’t install them or that they wouldn’t be “supported”? Those are two different things.

I'm aware they're two different things. Believe it or not, the rest of Hacker News is not five years old.

It's very easy to misunderstand things due to phrasing. I wouldn't take it personally, nor would it surprise me if a 30 year old friend of mine got confused.

Haven’t gotten to that part yet! Maybe I will on my next walk. But I would guess that he was talking about Linux virtualization being good enough that you wouldn’t need to do this and/or no Bootcamp support?

Follow up: I got to that point, I think the words were “we’re not direct booting an alternate operating system” in reference to not running Windows in Bootcamp on x86 and to reaffirm that Bootcamp was not a thing, not that there would be no support for booting other things.

An important thing to recognize is that every version of macOS (and iOS!) so far has retained some official way to boot a custom/unsigned/"unclean" kernel, specifically for kernel (or kernel extension) development.

When SIP (rootless v1) was introduced, macOS came with a way to disable it, for the sake of kernel developers. When APFS was introduced by default, macOS retained two workarounds for kernel developers: both the ability to boot from alternate APFS volumes within the APFS container; and also the ability to install to/boot from HFS+. And when the system volume became truly read-only in Catalina (rootless v2)—that's right, even that restriction could be overridden via csrutil, specifically to facilitate kernel development.

Apple is never going to lock themselves out of booting custom OSes that are almost, but not quite, macOS; because that's how new macOS gets made.

And, of course, as long as you can boot something that's not literally macOS; then that same mechanism can always be abused to boot something that is much less macOS, or in fact not macOS at all (but may still seem to be macOS, from the bootloader's perspective.)

Nitpick: SIP and rootless are the same thing.

Followup nit: the read only system partition is named as such and pronounced as an acronym.

Couldn't they retain 100% of the capability and lock everyone else out of it via signed software? For others that need to cooperate could they not hand out the capability to dozens of manufacturers without also providing that capability to millions of customers.

Apple doesn’t really seem to like ceding that control to users that way. It’d be really nice if you could change the root of trust on your device, but with Macs it’s either Apple or nothing, and on iOS it’s just Apple.

Except that the future is user space only extensions, as they re-iterated once more at this year's WWDC, while announcing additional support for newer userspace extensions APIs.

So actually, going forward they only need to make it easier for their own kernel teams, not third parties.

I would hope that there is always a way to get code execution in kernelspace, though it may require flipping more and more switches.

From the contents of the talks it is obvious that if that exists, it will be for Apple internal access only.

Given how they keep stressing the security and kernel stability during those sessions.

They are turning macOS into a proper micro-kernel, by changing the engines while keeping the plane flying.

Not on ARM macs. The option is missing. The only remaining option is for allowing older versions of the OS, which must still be signed by Apple.

The GUI does not display all options. You most likely can use csrutil to disable it, see the “Platforms State of the Union” WWDC talk.

I think I remember a WWDC talk mentioning that it would be possible via a revamped csrutil from recovery.

Edit: this one, about 19 minutes in: https://developer.apple.com/videos/play/wwdc2020/10686/

You can on Intel-based machines, as far as I know it is not clear yet whether you can on ARM-based systems.

Pressure for that came from Microsoft for Windows 8 certified devices:

"Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible. Disabling Secure Boot must not be possible on ARM systems."[1]

This requirement is no longer needed for Windows 10 logo certified x86_64 computer,[2] but I've yet to see a vendor actually take it out.

For SOC systems, at least if you wish to have Windows 10 Logo, it makes it optional if I'm reading their spec sheet correctly:

"Requirement 10: OPTIONAL. An OEM may implement the ability for a physically present user to turn off Secure Boot either with access to the PKpriv or with Physical Presence through the firmware setup. Access to the firmware setup may be protected by platform specific means (administrator password, smart card, static configuration, etc.)"[3]

That said, that's only for Windows logo certified devices. I'd assume if you don't intend to make you system Windows compatible then you can do whatever you want.

------

[1]https://docs.microsoft.com/en-us/previous-versions/windows/h...

[2]https://www.pcworld.com/article/2901262/microsoft-tightens-w...

[3]https://docs.microsoft.com/en-us/windows-hardware/drivers/br...

Reply on news.ycombinator.com