07.03.2016 23:40, Vladimir 'phcoder' Serbinenko пишет: > Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidj...@gmail.com> a écrit : > >> 07.03.2016 22:57, Vladimir 'phcoder' Serbinenko пишет: >>>> >>>>>>> I would also appreciate if distros would tell which patches they >> would >>>>>>> carry if 2.02 was released as it is now. If some patches are in more >>>> than 1 >>>>>>> distro we probably need to look into including them. >>>>>> >>>>>> Well, I have a bunch of patches that need to be clean up (or even >>>>>> re-examined), and I've also got the secure-boot branch here: >>>>>> >>>>>> https://github.com/vathpela/grub2-fedora/tree/sb >>>>>> >>>>>> Which is all the patches distros should be carrying to work with >> Secure >>>>>> Boot correctly. This branch is also recently rebased against master, >>>>>> though I'm not sure what the current thinking is regarding their path >>>>>> upstream. >>>>>> >>>>> >>>>> Personally I'd rather include support for it. I'm tired of linux vs. >>>>> linuxefi nightmare, and patches have been in the wild long enough. >>>> >>>> So what's the path forward, then? Just make all efi use linuxefi, like >>>> linux vs linux16? That's pretty close to what I've got already, except >>>> on arm where it's just "linux" in EFI mode as well. But we could make >>>> those aliases for the same thing on that platform easily enough. Or do >>>> you have something else in mind? >>> >>> RedHat/Fedora config is too platform-dependent and platform is detected >> at >>> mkconfig time rather than at runtime. This is a problem as runtime and >>> mkconfig can be different. Case that I see often is coreboot failing due >> to >>> use of Linux16 (which is a valid protocol for coreboot and is used for >>> memtest but Linux crashes with it) but other cases exist, like enabling >> or >>> disabling of SCM or moving disk to another computer. Can we fix this by >>> introducing some helper to detect it on runtime? It can either be a >>> function or a real command >>> >> >> Yes, of course, that was what I actually mean - get rid of special >> linuxefi and just fold processing into standard linux command. We can >> simply always call shim protocol if available on EFI; it should return >> success if secure boot is disabled so should be transparent. >> > Can you point to some patch to estimate code size of this change? What if
Here are patches from SUSE tree. https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-add-linuxefi.patch?expand=1 Note that it duplicates quite a bit of standard linux code. What we mostly are interested in is grub_linuxefi_secure_validate(). Also it reloads kernel after verification, which feels wrong, it should keep verified image in memory. https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-chainloader.patch?expand=1 This one is likely needed in full. https://build.opensuse.org/package/view_file/Base:System/grub2/grub2-secureboot-no-insmod-on-sb.patch?expand=1 Variant of it is needed - we cannot allow arbitrary module loading from untrusted location. > shim is not available? I suppose we need to check whether secure boot is enabled. If yes, we should fail boot because we cannot verify signature. > How big part of it is related to secure boot? Just > changing Linux boot protocol doesn't need FSF involvement. Accepting secure Patches currently use EFI stub to launch kernel but I think this is done simply to make code easier. We can continue to use the same load protocol as before, just add image verification. > boot might. I'd rather make verification framework and make secure boot > just one client, so module for it can be easily carried by whoever chooses > to implement it. How do you decide what verification method to use? > But this is probably 2.03 material > >> >> What is really a problem (or at least rather more involved) is >> chainloader. If secure boot is enabled, we effectively need to implement >> complete relocation of PE binary, bypassing EFI. I remember several >> interesting bugs in this code in openSUSE :) >> >> One more thing is module load. Currently patches disable it and use only >> modules included in core.img. I think we could relax it and allow module >> loading from internal memory disk. This will allow distribute signed >> image as grub-mkstanalone, making available full GRUB functionality. >> > Again, I feel like it's something for verification framework > >> >> >> >> > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
