Re: Bugs and tasks for 2.02[~rc1]

[Michael Chang]

On Mon, Mar 07, 2016 at 05:01:33PM -0500, Peter Jones wrote:
> On Tue, Mar 08, 2016 at 12:29:14AM +0300, Andrei Borzenkov wrote:
> > 08.03.2016 00:20, Peter Jones пишет:
> > > On Mon, Mar 07, 2016 at 11:57:33PM +0300, Andrei Borzenkov wrote:
> > >>
> > >>> 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.
> > > 
> > > No, they're doing it because that is the supported entry point for EFI
> > > in Linux.  We do not want EFI machines using other entry points.  It
> > > worked out terribly when we used to do this, and we don't want to start
> > > again.  I've Cc'd Matt Fleming, the upstream kernel EFI maintainer,
> > > because I'm sure he's going to agree with me.
> > 
> > So you mean that linux loader is currently broken on EFI?
> 
> None of the 3 OSes we produce ever uses it.  I don't know about what
> other distros ship, but a lot of them are using the secure boot code by
> default in all cases, so they're also going through the EFI stub.
> 
> My expectation is that on many systems it does work, but there are a lot
> of corner cases where things are not quite right.  In those cases you'll
> see problems like:
> 
> - less total memory available than expected due to e820 vs efi memory
>   map issues
> - the very real issue recently where grub set the type incorrectly on
>   some memory map entries, resulting in NVDIMMs winding up being marked
>   as normal allocatable memory.
> - 64-bit kernel on 32-bit platform like Baytrail can't work
> - some machines we won't get the virtual address map right and e.g. UEFI
>   variables just won't work
> 
> It goes on like this.

On the other hand, other grub2 functions like gfxpayload is broken with
linuxefi, as efi stub would set screen_info from scratch by gop protocol
and also linuxefi doesn't initialize it at all (as it seems not relevant
for the efi stub).

I think the switch to efi stub has to consider the existing grub.cfg
could still service without changes and function regression, or we will
end up in trouble of maintaining the config that is in continously
running, espeically for those not created by grub-mkconfig. 

Thanks,
Michael

> 
> -- 
>   Peter
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel