Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Secure Boot Works on M1 Series Macs

eclecticlight.co

Post reply on HN
Print view View original

71–80 of 117 posts

Re: How Secure Boot Works on M1 Series Macs

#71

Post by marcan_42 »

saagarjha wrote: post #5

The details seem ok, but the nomenclature isn’t: iBoot only handles hardware initialization and kernel bootstrapping. Once you’ve got system logging set up the kernel is in control and you’re into XNU, which is doing all the MACF, BSD setup and whatnot. You’re not going to get iBoot logs unless you set up a serial console.

This is correct. All the logs shown there are from XNU. The author confused verifying the root filesystem seal hash and the auxiliary kernelcache (containing kexts), which is what iBoot2 does, with the processes of validating the APFS snapshot and metadata against that hash and loading dexts, which is what the kernel and other parts of macOS do.

FWIW, you don't get iBoot logs even if you set up a serial console on M1s; these days it seems Apple only log over their "dockchannel" feature in their proprietary USB debug protocol, and we haven't figured out how that works yet. Even if you were to get them, on retail builds the logs are just message hashes, not readable text.

(I tried pointing this out in a comment to the article, but I guess it must be caught in some moderation queue)

Re: How Secure Boot Works on M1 Series Macs

#72

Post by duskwuff »

xoa wrote: post #66
duskwuff wrote: post #48

Earlier quoted context omitted.

> 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…

You're missing my point. What I'm saying is that, as things currently stand, all of the CPUs that Apple ships in products are functionally identical -- all of them share the same root of trust in ROM (afaik?), and it would take a significant effort for Apple to produce devices which differ from that specification.

> How? Most people will stick with defaults

By having an attacker deliver a system to a user with a custom root of trust -- which could mean anything from a state-sponsored attacker to an abusive partner.

Re: How Secure Boot Works on M1 Series Macs

#73

Post by duskwuff »

marcan_42 wrote: post #70
lovelyviking wrote: post #44

"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 y…

> On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers.

Even then, it isn't always obvious how to write that image to flash. Sometimes you get lucky and the downloadable BIOS is a full image of the serial flash chip, but sometimes it's a delta update, or the flash chip contains other data (like configuration) which isn't part of the public image.

And even then, there's a ton of other updatable firmware in a typical PC that isn't part of a BIOS update -- most video adapters and network devices will have at least a small flash chip on board, which may not be repairable at all if it's damaged.

Re: How Secure Boot Works on M1 Series Macs

#74

Post by marcan_42 »

argsnd wrote: post #40
CraigJPerry wrote: post #37

How does the boot wallpaper get selected in big sur or monterey? If you boot an m1 imac, it will use a wallpaper that matches the colour of your mac. I can see all the wallpapers are part of the blessed / sealed volume, what i can’t figure out is how it’s choosing with wallpaper to use? To be clear I’m talking about the very early boot wallpaper before file vault is unlocked. This is not the (user configurable) login…

As I understand it product information and iBoot1 are stored on an SPI flash chip in the device (which is hard to mess with from an OS unless you're quite determined to, but basically unrecoverable if you do), iBoot2 reads this information and uses it to select and fill in a device tree that is passed to your kernel. I think you might be able to find this information if you do: ioreg -p IODeviceTree -l My machine has…

This is correct. As I understand it, Apple have a database of product information and if you do wipe your SPI flash, it will be restored by phoning home during the DFU restore process (by identifying your machine based on its fused in ECID), though I've yet to try this. So it should be in fact fully recoverable.

This information is in the system configuration area, and gets inserted into the device tree template by iBoot2. You can see the template DT and what sysconfig entries it pulls data from if you extract it from an OS restore image instead of looking at the runtime DT with ioreg.

Re: How Secure Boot Works on M1 Series Macs

#75

Post by marcan_42 »

grishka wrote: post #34
xfr wrote: 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.

> You don’t see logs from iBoot. IIRC there's a serial console according to Asahi Linux people. Not sure if iBoot logs anything to it.

It does not. Apparently these days iBoot only logs to a proprietary USB debug protocol we haven't figured out yet.

Re: How Secure Boot Works on M1 Series Macs

#76

Post by marcan_42 »

londons_explore wrote: post #64
xfr wrote: 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...

It does not, not fresh and without boot time actions to take. Certainly not the laptops.

The Mac Mini used to have a larger delay dependent on the monitor attached, due to monitor detection times; about 7 seconds to the XNU kernel being launched, or 13 without a monitor (I guess it waits for monitor detection to time out), but now that Apple removed boot-time display support on those I imagine it no longer matters. The laptops have a much shorter time since they only have to deal with a well controlled internal display.

So it's possible that an M1 Mac Mini with no monitor attached pre macOS 12.1 took 20 seconds to boot to a login screen, but that's the worst case configuration.

(Yes, removing the bootloader framebuffer is stupid; I have a bug filed with them about this, but haven't gotten a response yet)

Re: How Secure Boot Works on M1 Series Macs

#77

Post by marcan_42 »

duskwuff wrote: post #73
marcan_42 wrote: post #70

Earlier quoted context omitted.

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 y…

> On x86 PCs, you can usually download a BIOS image, but to flash it you need hardware tools on most computers. Even then, it isn't always obvious how to write that image to flash. Sometimes you get lucky and the downloadable BIOS is a full image of the serial flash chip, but sometimes it's a delta update, or the flash chip contains other data (like configuration) which isn't part of the public image. And even then,…

Yup. On M1s Apple tries to make all external chips either use runtime loaded firmware or be bootloadable, both for security and recoverability reasons. I don't know if it's possible to truly brick an M1, but if it is you have to try really hard.

Re: How Secure Boot Works on M1 Series Macs

#78

Post by marcan_42 »

GeekyBear wrote: post #31
lovelyviking wrote: post #26

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…

And this isn't the case on M1 machines. On M1s, all blobs that remain after you launch Linux are sandboxed behind IOMMUs, so they cannot take over the system. Ignoring hardware backdoors (which you can never be sure don't exist, on any system), you can be reasonable confident that an M1 system doesn't have a (functional) backdoor running while you're running your own OS on it. Very few systems have this property; mostly only fully open boot systems like the Pinebook or Talos workstations. ~No x86 system does, not even the ones running Libreboot since they almost always have hardware with full DMA access running blobs.

Re: How Secure Boot Works on M1 Series Macs

#79

Post by marcan_42 »

smoldesu wrote: post #56
kmeisthax wrote: post #54

Earlier quoted context omitted.

You're not giving Hector Marcan enough credit. He was on Team Twiizers and fail0verflow; groups that did a lot of hacking to open up closed systems. It's not like he's unaware of the customer abuse that happens in the proprietary world. The "look beyond freedom" quote probably should also be looked at with the context that he's talking about the FSF, which has an odd habit of being extremely absolutist in ways that a…

I'm giving the dude all the credit he deserves. fail0verflow is amazing, the stuff they did with Nvidia Tegra/Nintendo Switch was nothing short of miraculous and insane; that doesn't change the cards at the table though, and it doesn't make me any less skeptical of where all this leads. Again, I've got no intention of stopping people who are making progress, even if it's progress I disagree with, but he still has to…

I fail to see how you can equate the Switch and PS4, platforms designed to disallow the user from running their own OS, and where the manufacturer actively works to stop any such attempts, to the M1, where the manufacturer actively invested in developing the infrastructure required to allow users to securely boot their own OS.

If you're talking about building a sustainable community so the end product is polished and upstreamed and ready for end users, I'd say we have that with the M1. Things are already getting upstreamed and there is more than enough momentum. This wasn't the case with PS4, which was just me and a few other fail0verflow folks putting together a proof of concept. It helps when you don't have to spend cycles finding exploits and can focus on delivering a working OS :)

Re: How Secure Boot Works on M1 Series Macs

#80

Post by est31 »

marcan_42 wrote: post #70
lovelyviking wrote: post #44

"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 y…

Google Pixel phones are phones though, and not personal computer devices like M1 Macs are. Phones have traditionally been more locked down. A fairer comparison would be to Chromebooks, which do have a screw to let you flash a different BIOS.
Post reply on HN