How Secure Boot Works on M1 Series Macs

> If you turn off the startup chime sound (which is a checkbox in system settings), that cuts out 2 seconds of iBoot time and makes it 14 seconds total.

Lol, wait, so the startup chime blocks the rest of the boot process?! I would have expected the system to be working on booting while the chime was playing.

Now I'm not sure whether I should keep the chime turned on. I like the chime, but I'm not sure I want to pay two extra seconds for it. :)

Yes, with a cable that connects to SBU pins: https://chromium.googlesource.com/chromiumos/third_party/hdc...

(if you have unlocked CCD and didn't lock yourself out of it — you could e.g. forget the password)

you can do whatever you want using flashrom with the SPI flash chips for both AP and EC.

> this design doc

Hmm, there's no timestamp for the page itself but the picture attachments are dated 2009.

> Cr50 RW storage can be recovered from the RO loader by using a physical USB-UART cable

That sentence sounds weird, not sure why it wouldn't be recoverable via the SBU cable — the RO firmware is just an earlier build of the same firmware that does offer the GSC/Cr50 UART among its consoles via SBU.

I'm not going to check though :D

> how the RO firmware is authenticated

According to OSFC presentation https://2018.osfc.io/uploads/talk/paper/7/gsc_copy.pdf

"RO public key in ROM, RW public key in RO" so they thought of that, the root of the root of everything is truly immutable silicon.

> e.g. glitching the Boot ROM

There are likely measures against this, since this is a "secure chip" designed in modern days by Google rather than some shitty vendor. But either way, attaching probes for voltage-glitching the root of trust is far beyond the capabilities of the proverbial "evil maid" :) And the glitching question should apply to Apple and whoever else as well.

> any end user with no specialized knowledge can follow a few simple documented steps with another machine and a USB cable and an app in the App Store (or idevicerestore) to fully, securely, and confidently restore all the writable firmware

What Google does for the "normal people" AP flash recovery: only the RW CBFS partition is writable from the AP, and for recovery it boots from an RO partition: https://doc.coreboot.org/security/vboot/index.html#recovery-... (there's a theme to everything the CrOS team does haha… surprise, the EC also uses the RO+RW mechanism)

Yes, this doesn't protect against the "I'm a normal regular user with no debug access and someone desoldered my SPI flash, tampered with it and soldered it back" but… come on :) Especially considering hard-to-open laptop cases and WSON-8 flash chips, that's just a ridiculous scenario to care about.

Tell that to all the governments who keep trying to get Apple to break into their own devices... It's not ridiculous at all, the NSA does this all the time (supply chain intervention). And WSON-8 really isn't that hard to swap, a hot air rework station will do it in a couple minutes. I've done much worse than that ;)

Good to hear the RO partition is also authenticated, though. My mention of glitching was mostly around whether there was trust placed in Flash at any point, since then a one time glitching attack could compromise the machine. You could still brick it by screwing up RO, but at least not compromise it. And again, those attacks aren't nearly as hard as you think. People have productionized these things for console modchips; that's at the level where someone with a cheap soldering iron can do it.

This section details the borked RW recovery scenario, and as far as I can tell refers to using a physical UART only, not the USB one: https://chromium.googlesource.com/chromiumos/platform/ec/+/c...

As for chip design, I'm sure Google did a better job than most random vendors (they all keep making the same mistakes...), but Apple has been doing chip security for much longer so they also have had quite a lot of time to build up experience in this area. I would trust Apple's chips over Google's (at least design quality wise), and I say this as a xoogler ;)

Actually, I think I can come up with an apt comparison. Google has crazy good production system security, probably better than anyone else; they've just been doing it for long enough, have been targeted by governments (China incident, NSA wiretaps), and have the motivation to just keep pushing things forward. Apple is on a very similar level with system/silicon security, in part for similar reasons. They're both just in their own league in those categories.

I think the irony would be less dramatic if the free software wasn't running on hardware constructed with slave labor. Put your eggs in whichever baskets you choose, but people's worries about the conflict of interests here is fully justified. Apple and open source are not friends, and while they'll be happy to tip their hat every once in a while (much like Microsoft's platitudes with WSL and GitHub), their ultimate goal is to stomp you out and expand control. Once again, nobody here has much interest in stopping you here; just don't be surprised when your blood, sweat and tears ultimately end up being used to grease the gears of their production line. We're talking about a trillion-dollar company that doesn't release their own device drivers or schematics; it's ridiculous that we even need to finish the job for them in the first place. It's hard to see this work as "noble" in the same way other free software projects are, at least to me.

sigh here we go again.

> I think the irony would be less dramatic if the free software wasn't running on hardware constructed with slave labor.

Why do you feel the need to direct criticism of Apple's business practices at me? I do not work for Apple.

> but people's worries about the conflict of interests here is fully justified.

Then don't buy the machines and move on with your life?

> Apple and open source are not friends

Neither are they enemies. The world isn't binary. I do not exclude from my life everything that is related to everyone who isn't explicitly my friend, do you?

> their ultimate goal is to stomp you out and expand control

Ah yes, stomp us out by... building machines we can use to run our own OS? They could've just not done that and we wouldn't exist.

> just don't be surprised when your blood, sweat and tears ultimately end up being used to grease the gears of their production line.

So which is, are they going to stomp us out or are they going to embrace the extra business we bring? You can't have it both ways, you know.

> We're talking about a trillion-dollar company that doesn't release their own device drivers or schematics; it's ridiculous that we even need to finish the job for them in the first place.

I find it fun finishing the job for them. This is exactly the kind of project I enjoy doing. If you don't, then choose a different free software to contribute to.

> It's hard to see this work as "noble" in the same way other free software projects are, at least to me.

So our project is inherently morally inferior to others because you simultaneously think Apple should've done the work for us and Apple are our enemies. ????????

Seriously, this makes no sense. You know Linux itself started out as a hobby OS with no corporate backing and tons of other drivers are reverse engineered, right? Do you also think Nouveau isn't noble? What about LineageOS? What about XBMC/Kodi when it started? Freedreno, Panfrost, and friends? All of those projects are or were about bringing free software to devices designed and manufactured by giant corporations without any support.

Heck, I got sued by a multinational for bringing Linux back to the PS3, and I still don't regret it. That work got upstreamed, by the way.