Hey why are you shipping laptops that don't trust the Microsoft 3rd party UEFI CA by default
17
41
228
Conversation
Basically any security technology can be abused to restrict user freedom - that means we need to push back against such abuses, not that we should necessarily reject the technologies in the first place
1
51
Needing to manually enable trusting third party boot chains is a minor inconvenience at most and not a restriction on what you can do. Their ecosystem has almost entirely theatrical implementations of secure boot and attestation. Many things would have to be fixed, this is one.
1
3
Proper approach would be only trusting first party boot chain by default, having a very easy way for users to add public key of other operating systems and filling in all the stuff that's missing like downgrade protection for secure boot itself. Attestation doesn't replace it.
1
3
It's an incomplete implementation of secure boot where there are multiple things missing for both firmware and the OS. One of the things they would need to do to turn it into a serious implementation is exactly this. Shim bootloader has no place in a serious implementation of it.
2
2
With the latest kernel release you *need* a shim if you want to enable lockdown mode and sign kernel modules.
There is simply no other way for you as a user to enroll a set of trusted keys in the kernel keyring at the moment.
I find this absurd.
2
1
This isn't true? Just enroll a signing key into db and also the kernel.
1
1
It is, actually. The db keys being loaded into the trusted keyring is from a rejected upstream patch.
The one that has been accepted is from Snowberg and enrolls keys from the MokList into the platform keyring. These variables are setup in the mok EFI configuration table.
2
Can't you build them into the kernel? Before Android had Android Verified Boot (AVB) defining how the last firmware stage verifies the signed vbmeta and the images specified from it via hashes / hash trees, you would build each key you wanted to be usable into the kernel keyring.
There are ways to include keys into the kernel at build time, there is also one thrown away after building the kernel.
The gripe however is that there is no way to include a key after this point, unless you use the shim.
1
Inject the key into the kernel, re-sign the kernel, use the same key in db. It's not trivial, but it's possible.
1
Show replies