Re: Bugs and tasks for 2.02[~rc1]

[Michael Chang]

On Mon, Mar 07, 2016 at 10:07:58PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> Le lun. 7 mars 2016 23:01, Peter Jones <address@hidden> a écrit :
> 
> > 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
> >
> Most of it sounds like just moving code around and not fixing the real
> issues. E.g. nvdimm issue can bite on a different way if GRUB itself
> mistreated nvdimm or passes bad info to another OS. Switching to linuxefi
> is not a reason not to fix real issues

I think some issues like the scarcity of e820 entry can only be fixed
cleanly in uefi stub. And also, the uefi stub is required for some magic
to happen, like verification.of signed kernel module.

Last but not least, it helps in eliminating duplicated bugs, as what we
are all familiar the ExitBootService() issue and it's stunt in elilo,
grub2 and uefi stub. Why not jumping to the same ship and have it fixed
once and for all.

Thanks,
Michael

> 
> >
> > It goes on like this.
> >
> > --
> >   Peter
> >

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