Hacker News Reader

> For example intel systems (and Android) run resident supervisor code you can't get rid of, and that can do remotely initiated updates you have no control over. That's not so on Apple silicon.

The Oxide Computer folks wrote their own AMD boot loader and have an entire chain of trust and apparently (?) basically got rid of the supervisor code (Ring -2 and -3). They also have custom motherboards with third-party BMCs.

Could something similar be done on Intel?

I suppose it's possible, after all if the thing can phone home and update itself, that could be spoofed so it updates itself with your code.

However if that phone home feature is read only, it could always just re-root itself.

> Could something similar be done on Intel?

Yes: https://duckduckgo.com/?q=%253Asite+phoronix.com+'Dasharo'

What good does that bring if Apple shuts down the project?

Also, I don't believe Apple has no backdoors and such. They basically made it impossible to be root on your iPhone, so you don't think they have a almighty-super-superuser mode on their laptops that only they can use? Wishful thinking if you ask me.

>What good does that bring if Apple shuts down the project?

How could they do that? They could cease providing the facilities the project relies on in newer chips, but the existing chips, er, exist. They could stop making chips all together and go back to intel. It's not a useful hypothetical.

>Also, I don't believe Apple has no backdoors and such. They basically made it impossible to be root on your iPhone, so you don't think they have a almighty-super-superuser mode on their laptops that only they can use?

It's possible such a thing exists, of course, it's possible on intel, or AMD, or any ARM chips, or any chip at all. However such a back door, if discovered, would not be accessible only to them. It would have the same problem that all such backdoors have, in that if Apple can exploit it, others can exploit it. Apple very heavily relies on the claim that they have no such back door, and they have relied on this as a legal defence, and frankly it's hard to see how they would benefit from having such a back door. A chunk of their business model and legal liability protection depends on not having such a back door.

>Wishful thinking if you ask me.

If you say so, this is all about relative risk. However what reason might anyone have for thinking that any other platform, such as Intel with it's proprietary supervisor code with remote updatability, is more under the control of the user? There may be platforms that have a better security architecture that's more under the control of the user, but I can't think of any of the major ones that does. Which would you suggest?

> Apple very heavily relies on the claim that they have no such back door

And, at least in the case of their private cloud compute, they encourage third party audit of their claims and even provide a virtual research environment running an instance of their PCC on your mac.

The UK explicitly requesting a backdoor to iCloud's advanced data protection forcing Apple to pull the service instead also tells me their claims are legit.

It's certainly possible a backdoor exists in hardware instead, or elsewhere in the stack but given Apple's surprising relative openness for how they implement their privacy products & the research papers they put out I'm inclined to believe them for now. (I say relative because its not open source, which is the only way to be 100% certain, but their research papers are surprisingly in depth).

> How could they do that?

iBoot? Asahi needs iBoot to boot third-party volumes for Linux to run properly. Apple controls iBoot; if they burn an eFuse and disable third-party volumes in a "Security" update, Asahi cannot fight back.

You cannot boot macOS with an unsigned iBoot firmware, so writing your own bootloader isn't an option. If a fuse is burned, you also cannot downgrade to older firmwares. The entire system is designed to give Apple the ability to disable other OSes in a macOS update if they ever decided to.

iBoot firmware exists and is already in our hands.

Any manufacturer could put an eFuse in any of their hardware and lock it. No hardware can be proven not to have such exploits. That's the first point marcan makes in that post.

> Any manufacturer could put an eFuse in any of their hardware and lock it.

This is my point too, though. Do we trust Apple to not burn a hardware fuse if their community one-ups them? They've already done it on iPad and iPhone hardware when users find a boot ROM exploit. All that they'd need to do is push an update for "security" purposes, and then the new boot flow could refuse to boot into unsigned volumes or deny running unsigned bootloaders. There would be no way to downgrade.

This is basic ARM security architecture stuff, I'm a little shocked that people can't imagine how this type of lockout is possible. There are tons of commodity ARM boards that are effectively bricked and eFused to user-hostile security epochs.

What good would it do Apple to shut down the project?

There’s no IP misuse and the ability to boot an arbitrary OS is an intentional part of the design of M-series Macs. The built in lag time of the current situation ensures that macOS will never have its position as the dominant OS for Mac hardware challenged. Further, doing this would stoke the flames of the already red-hot internet Apple haters and unnecessarily burn goodwill. It’d be a loss across the board.

> … the ability to boot an arbitrary OS is an intentional part of the design of M-series Macs.

What? Where do you get that?

Because it explicitly has tooling for custom boot objects etc, and stated by asahi developers, maybe also apple people they know.

The Apple Platform Security[1] white paper describes the secure boot process for Apple silicon. The Mac boot process is significantly more configurable than the iOS boot process, and it allows operating in reduced security modes. (Including running locally signed operating systems.)

Apple knows how to build an iPhone: if they wanted to lock down a Mac they would have simply done that. There's something like nine pages detailing the differences. What word describes that other than "intentional" design? The fact that you can sign and boot a third party OS isn't an "accident" if it's documented, and there's no "exploit" because this is functionality the platform supports; anyone can do it with tools already present on the (Apple-signed) recovery OS.

They certainly don't provide great support for people wanting to develop [drivers for] these operating systems, but the platform was very clearly engineered to support booting them.

[1]: https://help.apple.com/pdf/security/en_US/apple-platform-sec...

I guess I'm missing something then. The Asahi blog says "Apple’s boot tooling will only work with what it considers to be a “valid” macOS installation inside an APFS container." Sounds very adversarial to "the ability to boot an arbitrary OS."

It basically just has to look like macOS in some trivial sense, it doesn't have to be macOS, there are no obstacles. The system is designed specifically to enable booting custom compiled kernels and former members of the Apple team have said booting other OSes was intentionally left open. The company just doesn't make any guarantees about that.

Where is it stated in official Apple communications that Apple laptops will always support other OSes like Linux?

There you have it.

If they don't guarantee it, then better not depend on it. Or waste your time on it.

This also holds for members of the Asahi team. Unless they don't mind that a decade or so of their working life goes down the drain in one decision from Apple management or Apple lawyers.

That is irrelevant for the laptops Asahi currently support or are working on supporting.

It’s the difference between “there’s no published standards other than the reference implementation for some of the API” and “there’s no published standards and extremely monolithic reference implementation design coupled to proprietary blobs and considerable effort spent on signing/boot chain authentication to prevent third party implementations”. Apple is currently the former.

marcan mentioned in a few of his livestreams that the design seems very much intentional, plus a few of the tweets by Xeno Kovah who worked on the bootloader: https://x.com/XenoKovah/status/1339914716454526979.

Why would Apple do that?

If they did, I still have macOS, an OS I can easily disable all runtime protections and security on, rig up into a kernel debugger, arbitrarily dump memory of other processes and so on. If Apple takes away our ability to easily boot alternative kernels, the tools are readily available to find...alternative ways around iBoot security, which is not ideal for Apple since iOS iBoot is mostly the same as it is on macOS.

I find it hard to believe that Apple would purposefully shoot themselves in their own feet, unless you also believe that they would lock down the Mac as much as an iPad, ever.

Kernel debugging on Apple silicon largely does not work in any useful way

> last time I looked at the schematics for one of those

When was the last time they looked at the schematics for one of the Apple machines? Oh, wait.