Someone wrote in [personal profile] mjg59 2013-02-13 08:56 am (UTC)

Resigning Drivers and other Blobs

I'm not sure, if it makes sense to start this thread so late in an old post, as I find this very important. I would really appreciate feedback on this. I might repost this, if I get none within a week or so.

It's great that Microsoft provides the infrastructure to sign our own code to deal with the bootstrap issue. But does this imply, that everyone also needs to to trust anything they sign? If not, do we have to trust anything Google signs on Chromebooks?

I think it is really important that the next UEFI specification mandates that, there is not only a uniform key/hash management application for the initial boot, but also that anyone providing the initial OS must also provide a way to replace signatures on binaries with those of custom keys.

IIRC, the format of a signed binary can only facilitate a single signature.

Why must a keep trusting /everything/ that Microsoft/Google, sign once I have my own key installed. I should be able to remove their key and either selectively white list (via hashes) or sign not only initial boot images but also specific kernel modules/drivers.

I'm fine with using your Shim for the initial setup, but then I want to install my Shim that I've built and that was signed by me. I don't want to trust NVidia's proprietary driver, but only nouveau that was signed by debian, fedora, .

I'm wondering whether this should be done within the uniform UEFI application. Theoretically I'm fine if can boot into a minimal system without all modules available but enough so that I can replace signatures in modules/drivers or enroll hashes for specific drivers that I decide to trust without trusting everything that was signed by the Microsoft/Google keys. But this minimal system should also have a consistent user experience that doesn't differ between the UEFI/OS implementations.

Does anyone have something like this on their To-Do list? And what would it take to put that on someones To-Do list... seriously. Until the User can practically control the trust chain, SecureBoot is not Secure, even if your effort have relieved the Restricted Boot issue a lot. Thanks again though for doing that for us!

Post a comment in response:

If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org