On Mon, 2016-11-21 at 16:16 +0000, Ard Biesheuvel wrote: > On 16 November 2016 at 18:11, David Howells <dhowells@xxxxxxxxxx> > wrote: > > From: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> > > > > Secure Boot stores a list of allowed certificates in the 'db' > > variable. This imports those certificates into the system trusted > > keyring. This allows for a third party signing certificate to be > > used in conjunction with signed modules. By importing the public > > certificate into the 'db' variable, a user can allow a module > > signed with that certificate to load. The shim UEFI bootloader has > > a similar certificate list stored in the 'MokListRT' variable. We > > import those as well. > > > > This sounds like a bad idea to me. For the standard databases like db > and dbx, we can rely on the firmware to ensure that they are what you > expect. Actually, I think it's a bad idea for the opposite reason: Shim explicitly pivots the root of trust away from the db keys to its own Moklist keys. We have no choice and are forced to trust db for the secure boot part, but once we're in the kernel proper, I'd argue that we would only want to trust the pivoted root, i.e. Moklist. Trusting both could generate unwanted consequences, like pressure on Microsoft to sign modules or worse, pressure on OEMs to include module keys or hashes ... or worst of all OEMs signing external modules. > For MokListRt, not so much: anyone with sufficient > capabilities can generate such a variable from userland, and not > every arch/distro combo will be using shim and/or mokmanager. (The > debates are still ongoing, but my position is that there is no need > for shim at all on ARM given that the M$ problem only exists on x86) OK, so on this point, I'm already not using Shim on my x86 box. However, what you find if you're using grub is that because grub doesn't do signature verification, you still have to use the shim protocol callout, so you need something between UEFI and grub to load at least this protocol. I suppose this would go away once we can persuade grub to verify signatures. James -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
