Hector Martin

Some more context to this: while a customKC (which is basically "something resembling Mach-O kernel file to transfer control to instead of the original kernel") payload is indeed unsigned, it's hash is still signed by machine-specific key, so chain of trust is preserved.https://twitter.com/never_released/status/1339753170629746690 …

The user can break it on their first stage, if they choose to, but there's no way to "disable SecureBoot" on Apple Silicon Macs (as in "disable signature verification entirely").

Big thanks to @XenoKovah for designing the mechanism. Looking forward to see the exciting new bootloaders and kernels (TianoCore? Linux? *BSD? Redox?) that the community will end up using it for.

What's the motivation for having this requirement, by the way? Obviously you can break it (as I will as my step 0, for practical purposes, regardless of whether we try doing secureboot linux in the future), but why not just let you skip that step?

There are multiple use cases for running custom code in kernelspace. For some the customer still wants it to run with high security. For others they don't care about security anymore.

In general the threat models which include physical tamper quickly get too complex for most people to effectively reason about (but this is why I put more detailed docs into the queue for later release.)

So people don't really know just how vulnerable they're becoming when they disable any of the security mechanisms. So the goal was to make it architecturally default to still being secure / proving customer-consent for the next stage boot object ...

not just *any* boot object, which would be what they get if it skipped directly to "no security" like the previous T2 design. In so doing, less people will be shooting themselves in the foot and running with effectively no security and thinking they have some security