Live data from Hacker News

How Secure Boot Works on M1 Series Macs

eclecticlight.co

31–40 of 117 posts

Re: How Secure Boot Works on M1 Series Macs

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

>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 version or how it's been modified since we don't have the source code. We do know that with it there Neither Linux nor any other operating system have final control of the x86 platform.

https://www.zdnet.com/article/minix-intels-hidden-in-chip-op...

Re: How Secure Boot Works on M1 Series Macs

#32
post #6

completely insecure if you are not the only one with the key

It really depends on the threat you are planing against. If for some reason I'm target of US government - I'm screwed anyway. If my concern is trusting the laptop after I left it in train station and got it back from some random dude - it's good enough.

How about much simpler scenario, no threat at all. Just dumb bug in software that puts your computer in DFU mode that says, please connect it to another Mac. Nice isn't it? And then you should run and find 'another mac'. What if there are no other macs around? What if you travel and have no connection to the internet or it's limited ? This is not a hypothetical situation, this is exactly what have happened in my case. And then you are stuck in the field without any way to recover your machine. Nice isn't it?

"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

Re: How Secure Boot Works on M1 Series Macs

#33
post #20

Earlier quoted context omitted.

How do you secure something when other's know the secret? There has to be some "secret" (aka key) that some definition of "you" only knows, that the system then tests against (hopefully via some kind of asymmetric system or hash).

Public/private keys? In this case, since others already know it, signing something is sufficient.

Yep. The signing is done with public/private (aka asymmetric) keys and some kind of hashing mechanism.

Re: How Secure Boot Works on M1 Series Macs

#34
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.

Re: How Secure Boot Works on M1 Series Macs

#35

Earlier quoted context omitted.

That's not what I was talking about... secure boot and locked boot loaders are "protected" with keys held by manufacturers...

Then 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"?

> BoorishBears - 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"?

because you don't even have the key? not sure where passcodes came from

Re: How Secure Boot Works on M1 Series Macs

#36

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…

therefore I've said this before:

The full control of devices you own is absolutely essential. It requires a complete transparency of basic components like cpu micro-code, firmware and hardware otherwise it can and will be abused.[0]

.. unless everything is absolutely transparent including microcode and hardware it is not acceptable as freedom respecting solution.[1]

then I've got unexpected opposition from the one who is making linux for M1 ( marcan_42). If even him fail to understand the consequences of accepting such hostage situation with Apple devices and claim "Freedom isn't the answer." [2]. If even he is ready to downgrade discussion to the personal disrespect toward people like me [3] who merely trying to point out the the danger of the hostage situation while go 'easy' on Apple and ready to justify all of their current mistakes then we have a serious problem. I do not wish to use the term "doomed" but probably we observe limited ability of highly technical minds to resist to the primitive brainwashing and manipulation the big companies provide by presenting it as a norm to trade 'freedom' for the 'safety' . Some people can't even think a few steps forward and understand that by helping companies to promote such agenda we'll end up with loosing both 'safety' and 'freedom'.

[0] https://news.ycombinator.com/item?id=29658817

[1] https://news.ycombinator.com/item?id=29675597

[2] https://news.ycombinator.com/item?id=29676524

[3] https://news.ycombinator.com/item?id=29691816

Re: How Secure Boot Works on M1 Series Macs

#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 screen wallpaper. This is a fixed choice.

My best guess is an nvram key but i didn’t spy an obvious one.

Re: How Secure Boot Works on M1 Series Macs

#38

Earlier quoted context omitted.

It really depends on the threat you are planing against. If for some reason I'm target of US government - I'm screwed anyway. If my concern is trusting the laptop after I left it in train station and got it back from some random dude - it's good enough.

How about much simpler scenario, no threat at all. Just dumb bug in software that puts your computer in DFU mode that says, please connect it to another Mac. Nice isn't it? And then you should run and find 'another mac'. What if there are no other macs around? What if you travel and have no connection to the internet or it's limited ? This is not a hypothetical situation, this is exactly what have happened in my case…

Just use https://github.com/libimobiledevice/idevicerestore on a Linux or Windows machine.

Yes, if you don't have internet access you have a problem, but I'm personally happy enough with the benefits of this security model that I'm willing to accept the tradeoff.

Re: How Secure Boot Works on M1 Series Macs

#39

Earlier quoted context omitted.

It really depends on the threat you are planing against. If for some reason I'm target of US government - I'm screwed anyway. If my concern is trusting the laptop after I left it in train station and got it back from some random dude - it's good enough.

How about much simpler scenario, no threat at all. Just dumb bug in software that puts your computer in DFU mode that says, please connect it to another Mac. Nice isn't it? And then you should run and find 'another mac'. What if there are no other macs around? What if you travel and have no connection to the internet or it's limited ? This is not a hypothetical situation, this is exactly what have happened in my case…

[deleted]

Re: How Secure Boot Works on M1 Series Macs

#40

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:

  "housing-color" = 
Post reply on HN