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