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 …
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.)
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.