> I'm actually not talking about UEFI storage, just the UEFI secure boot > database. I think we might come up with a viable model for adding keys > from a UEFI variable that isn't part of the secure boot database.
You also need to be able to remove or not trust the existing ones including the Microsoft keys. Not trust probably makes the most sense. If you trust those you are dead already, because there are existing signed kernel images and Windows boot images that have known remote ring 0 exploits so I can just boot one of those and own you. Since you are never going to make a Fedora update blacklist the previous kernel image it's also not going to get fixed because it's a usability problem. > The reason for keeping this boundary is to do with the politics of > breaches. If we get a breach to the secure boot boundary, Microsoft > and all the ODMs will help us hunt it down and plug it (They have no > option because Windows is threatened by any breach to that boundary). > If we use the keys beyond the secure boot boundary and get a breach > that only affects our use case no-one will help us because no-one will > care. Also the politics of control. A world where Red Hat, Microsoft and some other parties together effectively control who gets to load modules into a free OS for most users is not a good one - whatever the module licence. Plus I'd have thought if your lawyers are scared of signing keys they'll be even more terrified of the competition law impacts of gatekeeping 8) Alan
