Re: Bugs and tasks for 2.02[~rc1]

[Peter Jones <pjones@redhat.com>]

On Mon, Mar 07, 2016 at 08:40:58PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 21:33, Andrei Borzenkov <arvidjaar@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.

-- 
  Peter