10.03.2016 17:21, Matt Fleming пишет: > On Wed, 09 Mar, at 11:15:16PM, Andrei Borzenkov wrote: >> 09.03.2016 18:18, Matt Fleming пишет: >>> On Tue, 08 Mar, at 07:57:35AM, Andrei Borzenkov wrote: >>>>>> - 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? >>> >>> The biggest issue is that there's no way right now for a boot loader >>> to tell the kernel that it needs to use a translation layer when >>> calling EFI services (we refer to this as the "thunk" layer in the >>> kernel) without going via the EFI handover protocol. >>> >>> Obviously this could be achieved by writing the required code for GRUB >>> but it would be largely duplicated from the existing code EFI boot >>> stub code in the kernel. I don't think it's worth the effort. >>> >> >> That sounds like this should be supported irrespectively of secure boot >> then. > > I'm not sure what you mean here. Are you suggesting to add support for > the EFI handover protocol to the regular linux loader? >
Yes. >>> The kernel figures out when to use the thunk layer by taking note of >>> which EFI handover offset entry point the boot loader entered from, we >>> include both a 32-bit and 64-bit entry point when CONFIG_EFI_MIXED is >>> enabled. >>> >> >> OK, looking at linuxefi patch, the only real difference from normal >> linux loader is that it restricts memory allocations to below 1G. Is it >> kernel requirement? > > No, I'm not aware of such a requirement for modern kernels, though > it's possible there was a historical restriction. > >> What to do if kernel is compiled without CONFIG_EFI_MIXED support? >> Should we fall back to traditional handover without calling into EFI >> stub or fail load completely? > > Falling back to the traditional handover and disabling EFI runtime > services would be the best way to go. You can see whether mixed mode > is enabled by inspecting the ->xloadflags in the bzImage header. > OK, even more reason to support EFI handover as part of normal linux loader. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel