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. 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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
