On 10/24/2016 06:20 PM, Theodore Ts'o wrote: > On Tue, Oct 18, 2016 at 07:52:13PM +0800, Paul Wise wrote: >> It was posted to bug #820036, which is tracking Debian support for >> secure boot. Peter was advocating quite correctly that as well as >> having our copy of shim (the first-stage bootloader on secure boot >> systems) signed by Microsoft, we should also have a copy signed by a >> Debian signing authority, so that users can theoretically choose to >> distrust the Microsoft key. IIRC, unfortunately in practice that is >> unlikely to be possible since various firmware blobs are only >> Microsoft-signed. > It's probably not possible for Debian to deal with this, but I could > imagine a user (perhaps someone who is using Debian for their entire > organization, etc.) who is willing to download firmware blobs from a > trusted source (e.g., directly from the vendor), and then verify the > Microsoft signature as a double check, and then resign it with their > own signing authority key. > > To the extent that we could easily support this particular use case, > it might be a good thing. (I doubt Debian is going to want to get > into the business of verifying and then resigning firmware blobs.) Depends if you are then able to flash it into the addon card you have (think VGA BIOS on an NVIDIA graphics card), which requires a) access to some flash process and b) depending on that potentially a signature trusted by the device to accept the update. Otherwise you end up with no graphics output on bootup because the system is not trusting the blob on your graphics card to run. If you screw it up too heavily, you can render your machine unbootable as well. (I know a coworker succeeded in doing that when modifying the key set.) Nothing a SPI programmer can't fix, but it'd be annoying nonetheless. Kind regards Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature