18 ms·
How Secure Boot Works on M1 Series Macs
- willis936 5y agoThis 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.
- javajosh 5y agoType F12 and then paste the following string and hit enter, ya hacker: document.querySelectorAll('code').forEach(elt => elt.style.backgroundColor = 'lightGrey')
- dylan604 5y agoI don't have an F12 on my keyboard. Should have been considered since we are discussing the boot sequence of Mac. Just sayin
- xfr 5y agoThere 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.
- sys_64738 5y ago> I have no idea what this means: Userland is instantiated.
- grishka 5y ago> 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.
- marcan_42 5y agoIt does not. Apparently these days iBoot only logs to a proprietary USB debug protocol we haven't figured out yet.
- londons_explore 5y ago> 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...
- breakfastduck 5y agoThat 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.
- marcan_42 5y agoIt 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)
- saagarjha 5y agoThe 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.
- marcan_42 5y agoThis 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)
- zaxbeast 5y agocompletely insecure if you are not the only one with the key
- sys_64738 5y agoWhich key?
- zaxbeast 5y agoThe secret key that Apple holds?
- diontron 5y agowhich is literally the case for any security system lol
- zaxbeast 5y agoYet companies still try to convince you otherwise...
- BoorishBears 5y agoShow me where Apple says they protect against attackers who already have your passcode.
- zaxbeast 5y agoThat's not what I was talking about... secure boot and locked boot loaders are "protected" with keys held by manufacturers...
- BoorishBears 5y agoThen your comment doesn't make sense? You wrote: > completely insecure if you are not the only one with the key What key is shared between you and the manufacturer here? There's signing keys and there's passcodes, which ones are you "not the only one with"?
- rubicks 5y agoCould anyone explain how the firmware (implementing UEFI, I assume) interacts with the components described here? My knowledge is limited to Tianocore edk2 on amd64 platforms.
- monocasa 5y agoThere isn't UEFI or anything like it. iBoot takes that place.
- microtonal 5y agoThere is no UEFI, only a simple boot ROM and the first stage of iBoot is in NOR flash. The rest is all on NVMe. There is a detailed description here: https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot https://github.com/AsahiLinux/docs/wiki/M1-vs.-PC-Boot
- marcan_42 5y agoI should update that, there are a few minor inaccuracies, but it's mostly still correct given our present knowledge :)
- deleted 5y ago[deleted]
- Jabed30 5y ago[dead]
- deleted 5y ago[deleted]
- CraigJPerry 5y agoHow 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 screen wallpaper. This is a fixed choice. My best guess is an nvram key but i didn’t spy an obvious one.
- argsnd 5y agoAs 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: "housing-color" = <01000000000000000000000001000000>
- marcan_42 5y agoThis 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.
- lovelyviking 5y ago"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 https://news.ycombinator.com/item?id=29704923
- judge2020 5y agoThis has been a thing on iOS since I want to say the iOS 7 days, ie. the introduction of shsh2 blobs, and it ultimately hasn't been an issue.
- InvertedRhodium 5y agoUnless, of course, you need to perform a low level recovery when Apples servers are unavailable, for whatever reason. Then, it seems that it would be quite the problem.
- afandian 5y agoOr they do the equivalent of forgetting to update a root CA, orphaning your machine, as happened to a family member of mine.
- marcan_42 5y agoFor 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.