Le lun. 7 mars 2016 22:14, Peter Jones <pjo...@redhat.com> a écrit :
> On Mon, Mar 07, 2016 at 08:40:58PM +0000, Vladimir 'phcoder' Serbinenko > wrote: > > 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 > > shim is not available? How big part of it is related to secure boot? Just > > changing Linux boot protocol doesn't need FSF involvement. Accepting > secure > > 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. But this is probably 2.03 material > > John Sullivan has, in the past, expressed that grub calling out to shim > for secure boot validation is a reasonable method; I'm not sure why we'd > need more involvement, but if you feel we must, okay. I'd rather see > support for the only strong validation system we have in the real world, > than arbitrary frameworks. But I agree, we're probably talking about > something after 2.02. > Framework is just an elaborate word for separating verification code from support around it like retention of the file in memory or determining files to check. I know of several users for this and would like to avoid code duplication > > -- > Peter >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
