On 22.01.2014 00:29, Colin Watson wrote: > On Tue, Jan 21, 2014 at 05:29:03PM +0100, Vladimir 'φ-coder/phcoder' > Serbinenko wrote: >> This part is from RH "Secureboot" patch. Few things are right about that >> patch. Whatever signature verifications would need to be integrated with >> signatures framework (I have some scratch in phcoder/file_types) > > The RH SB patch is not ideal from a pure GRUB point of view. But > realistically, in order to actually be useful in the (unfortunate) SB > ecosystem that exists today where Microsoft is the effective root of > trust on most mass-market hardware, we need to have a non-GPLv3 > component that is what the firmware actually loads directly, it needs to > be able to do signature checking in order to chain to GRUB, and it's > unlikely to be helpful for the signature checking to be implemented in > two places - so the scheme where GRUB calls out to shim seems to be an > uncomfortable necessity there. > Distros start shipping signed kernels with signing in EFI way, including Ubuntu. Similar proposal to add GnuPG signatures was met with scepticism (if I remember correctly, including from you). On coreboot systems it can be interesting to verify that kernel came from Ubuntu and the only current way to do so is EFI-style signature. > I have no objection to there being some more native mechanism in GRUB > that works when users take control of their own trust chain; that seems > entirely consistent with the FSF's goals regarding UEFI. But I'm having > trouble seeing how we could make use of it effectively in order to > bootstrap free operating systems on firmware that only has the Microsoft > keys in place, which I think is just as important now as the ability to > run GNU software on proprietary Unixes was back in the 1980s. > > (Unless, of course, you mean that there ought to be something integrated > into GRUB's signatures framework that would let it optionally call out > to shim; that would be an interesting possibility.) >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
