Live data from Hacker News

How Secure Boot Works on M1 Series Macs

eclecticlight.co

61–70 of 117 posts

Re: How Secure Boot Works on M1 Series Macs

#61
post #3

This is an interesting walkthrough. It would be nice if the code blocks were more distinct from the comments; some combination of indentation, vertical space, coloring.

Type F12 and then paste the following string and hit enter, ya hacker: document.querySelectorAll('code').forEach(elt => elt.style.backgroundColor = 'lightGrey')

I don't have an F12 on my keyboard. Should have been considered since we are discussing the boot sequence of Mac. Just sayin

Re: How Secure Boot Works on M1 Series Macs

#62

Earlier quoted context omitted.

>If you completely don't trust Apple, then you absolutely should not use their hardware at all. So some level "trust Apple" is simply a security axiom on this platform. It is not about trusting Apple or any other company for that matter. It is about tendency and attempt to make it a norm/legalize to sell personal computers without respecting right of the owner to have a full control over their own computer. If owner…

> It is about tendency and attempt to make it a norm/legalize to sell personal computers without respecting right of the owner to have a full control over their own computer. If owner cannot fully control own computer this computer cannot be called 'personal' anymore. I have bad news about Intel CPUs. >[Intel] processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what vers…

I thought that MINIX was running on the Intel Management Engine, not the main CPU.

Re: How Secure Boot Works on M1 Series Macs

#63

Earlier quoted context omitted.

> It is about tendency and attempt to make it a norm/legalize to sell personal computers without respecting right of the owner to have a full control over their own computer. If owner cannot fully control own computer this computer cannot be called 'personal' anymore. I have bad news about Intel CPUs. >[Intel] processors are running a closed-source variation of the open-source MINIX 3. We don't know exactly what vers…

I thought that MINIX was running on the Intel Management Engine, not the main CPU.

That has full access to, and modification/control ability over, the main CPU.

Re: How Secure Boot Works on M1 Series Macs

#64
post #4

There are several inaccuracies. Everything after “Darwin Kernel Version 21.2.0” is XNU, not iBoot. This is when macOS starts according to the diagram. You don’t see logs from iBoot. I have no idea what this means: > The end of the kernel-only phase, which is entirely iBoot, comes almost 20 seconds after the start.

> comes almost 20 seconds after the start.

Wait... an M1 Mac takes 20 seconds to boot?? A middle of the range windows machine in 1996 booted quicker than that...

Re: How Secure Boot Works on M1 Series Macs

#65
post #4

There are several inaccuracies. Everything after “Darwin Kernel Version 21.2.0” is XNU, not iBoot. This is when macOS starts according to the diagram. You don’t see logs from iBoot. I have no idea what this means: > The end of the kernel-only phase, which is entirely iBoot, comes almost 20 seconds after the start.

> comes almost 20 seconds after the start. Wait... an M1 Mac takes 20 seconds to boot?? A middle of the range windows machine in 1996 booted quicker than that...

That doesn't seem right - though I must say macs have always felt to me as if the boot->user desktop takes way longer than other OS'es.

I guess the M1 counterpoint is the very, very fast sleep->wake speed.

Re: How Secure Boot Works on M1 Series Macs

#66
post #23

Earlier quoted context omitted.

For the record, I'm in favor of legal mandate that hardware owners have the buy-time option to enable adding their own keys to any root trust stores on their devices. However, that'd be in addition to Apple's keys and wouldn't be about the security of Apple's keys, because Apple is part of the fundamental trust foundation if you buy a Mac or iDevice. Period. The devices are massively vertically integrated, right down…

> hardware owners have the buy-time option to enable adding their own keys to any root trust stores on their devices Would you really be more comfortable knowing that your hardware vendor had the capability to produce machines with a low-level, unremoveable backdoor? I'm not sure I would. A feature like that can be used against users more easily than it can be used by those users.

>Would you really be more comfortable knowing that your hardware vendor had the capability to produce machines with a low-level, unremoveable backdoor?

What? They do. Apple absolutely has the capability to build any or all machines with low-level unremoveable backdoors, like, in the freaking processor if they wanted. I'm not clear on what your issue is here. The current state of affairs is that for devices like the iPhone, the manufacturer can setup a secure software tree where the root of trust contains only their keys. And for many (if not most) of their customers that's a good thing, because in their threat model running their own arbitrary code is of lower utility and much higher risk then getting social engineered into bypassing key protections or the like. There is important power in grouping together buying decisions in an unbypassable way, it's why the likes of Facebook for example cannot insist on bypassing iOS privacy protections. They can't pick people off, because people literally do not have the choice. Facebook must deal with Apple for the ~97% (or whatever it is who don't/can't jailbreak) majority of users.

However there are real issues with that too for a sizable number of owners. So all I want is that there be an option at purchase time which allows owners to load their own root keys. The whole chain of trust infrastructure is still there, but technical users or those with specific needs can then run their own (and still be better off). Making it buy-time means that users who want to ensure they cannot be compelled later can still do that too. Nobody loses.

A feature like that can be used against users more easily than it can be used by those users.

How? Most people will stick with defaults, and I'd be ok with Apple or whomever qualifying an open device with reduced software support or some small charge for example too. And once it's been sold, it's the same as currently. I think that's a reasonable tradeoff.

Re: How Secure Boot Works on M1 Series Macs

#67
post #3

Earlier quoted context omitted.

Type F12 and then paste the following string and hit enter, ya hacker: document.querySelectorAll('code').forEach(elt => elt.style.backgroundColor = 'lightGrey')

I don't have an F12 on my keyboard. Should have been considered since we are discussing the boot sequence of Mac. Just sayin

It doesn’t appear if you press fn?

Re: How Secure Boot Works on M1 Series Macs

#68
post #3

Earlier quoted context omitted.

Type F12 and then paste the following string and hit enter, ya hacker: document.querySelectorAll('code').forEach(elt => elt.style.backgroundColor = 'lightGrey')

I don't have an F12 on my keyboard. Should have been considered since we are discussing the boot sequence of Mac. Just sayin

There are mac keyboards that don't have function keys? I suppose the ones without numeric keypads don't - still boggles my mind those abominations exist...

Re: How Secure Boot Works on M1 Series Macs

#69
post #68

Earlier quoted context omitted.

I don't have an F12 on my keyboard. Should have been considered since we are discussing the boot sequence of Mac. Just sayin

There are mac keyboards that don't have function keys? I suppose the ones without numeric keypads don't - still boggles my mind those abominations exist...

TouchBar, nuff said

Re: How Secure Boot Works on M1 Series Macs

#70

"When Apple's servers go down you lose the ability to do low-level recovery on these machines anyway, since DFU flashing requires phoning home to get a ticket for your machine as well as low-level configuration data" https://news.ycombinator.com/item?id=29704923

For comparison, note that you can't do low level recovery at all on e.g. Google Pixel phones. Lose the contents of your storage there and the phone is bricked, as Google does not provide the low level flashing tools and signed images to do that. Apple does, with the phone home caveat.

On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. So it's better in that you don't need to phone home, and worse in that you need specialized tools to do it. You might also lose serial numbers and other personalization information.

Note: "Factory" images aren't this (and that's a misnomer, they aren't what is used at the factory). Those are OS images. To flash them your bootloader needs to be intact. We're talking about recovering from complete loss of writable storage here - that requires OEM tools to boot low level recovery images from the boot ROM alone. Some of these have leaked, but for very few devices. Apple just gives all of this to you on macOS and we have an open source reimplementation of their DFU tooling (idevicerestore) that you can run on any OS to restore any M1 Mac or iDevice to any (signable) OS version. To this day, all non-beta macOS for M1 releases are signable; I imagine they'll only revoke old ones if a major security flaw is found that impacts device backdoorability or allows SEP compromise or so, and even then you could still install an older OS in reduced security mode, just not as the first OS installed during low level recovery.

Post reply on HN