Re: Bugs and tasks for 2.02[~rc1]

[Andrei Borzenkov <arvidjaar@gmail.com>]

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.