08.03.2016 06:40, 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. >>
SUSE allows switching off secure boot in YaST, this is relatively popular advice to users to work around some problems and quite a lot of users simply do not want to use SB at all (judging by forum posts). So it gets at least some use in the wild. >> 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 Do you have pointers to real-life examples? >> - 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. Fixed in beta3. >> - 64-bit kernel on 32-bit platform like Baytrail can't work Do you mean "32 bit EFI"? If yes, why is it a problem? >> - some machines we won't get the virtual address map right and e.g. UEFI >> variables just won't work >> This sounds like bug in GRUB that needs fixing anyway. >> 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. > Yes, any implementation should reuse as much of existing loader code as possible and only change handover method. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel