Le lun. 7 mars 2016 23:01, Peter Jones <pjo...@redhat.com> 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 > > It goes on like this. > > -- > Peter >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
