[Xen-devel] EFI + GRUB2 + Xen - Boot Services issues

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

Hi,

Vladimir, during my work on final multiboot2 protocol support in Xen on
EFI platform I stated that GRUB2 patch 0df77d793c0436be656f982d96d4edaea4993f96
(Implement multiboot2 EFI BS specification) may not give access to Boot
Services as we earlier expected.

In general above mentioned patch gives a way to prevent ExitBootServices()
call in GRUB2 which is good. However, it looks that this is only part of
the bigger puzzle. Sadly GRUB2 before jumping into the loaded image switches
x86 processor mode to 32-bit and disables PG bit in CR0. This is not native
EFI processor mode. Especially it is very painful on 64-bit EFI implementations.
Even if you can disable ExitBootServices() call later you are not able to call
Boot Services functions without switching processor mode (this is quite simple)
and recreating page tables (this could be quite complicated). I do not mention
that system table could be unavailable in 32-bit mode because pointer to it
is 64-bit and there is no guarantee that it will be placed below 4 GiB. However,
worst thing is that there is no access to ImageHandle which is needed to call
ExitBootServices(). Hence, I think that if MULTIBOOT2_HEADER_TAG_EFI_BS tag
is in force at least GRUB2 loader should not touch processor mode on EFI 
platform
and it should pass pointer to ImageHandle. I am aware that this is very 
intrusive
change and maybe we should consider reverting 
0df77d793c0436be656f982d96d4edaea4993f96
(Implement multiboot2 EFI BS specification) patch from GRUB2 version 2.02 at 
this
stage of development because there is no guarantee that this change will solve
all problems with BS. This way we avoid situation in which new feature is broken
from the beginning and we are not able to remove it.

Additionally, I discovered that BS could be overwritten during relocation 
because
grub_relocator32_boot() is called with last argument (avoid_efi_bootservices)
set to 0 even if MULTIBOOT2_HEADER_TAG_EFI_BS tag is in force.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel