[Xen-devel] [Xen Hackathon] EFI + GRUB2 + Xen

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

Hey,

Below you could find some ideas how to solve issues related to EFI + GRUB2 + 
Xen.
I would like to discuss them during Xen Hackathon.

Here is the excerpt from "EFI + GRUB2 + Xen - Boot Services issues" thread which
will paint current picture 
(http://lists.xen.org/archives/html/xen-devel/2014-03/msg00554.html):

*******************************************************************************

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

*******************************************************************************

Right now there is not solution for those issues. So let's think what we can
do to solve these problems.

What knowledge we need from EFI 64-bit platform to run Xen on it:
  - EFI tables/functions,
  - ACPI data,
  - memory map,
  - VGA (graphic card) mode,
  - EDD data,
  - MBR data.

Does GRUB2 provide above mentioned stuff on EFI 64-bit platform:
  - EFI tables/functions: YES,
  - ACPI data: YES,
  - memory map: YES,
  - VGA (graphic card) mode: YES as MULTIBOOT2_TAG_TYPE_FRAMEBUFFER tag;
    it is a chance to use that but it requires more investigation,
  - EDD data: NO,
  - MBR data: NO.

How we can get EDD and MBR from EFI 64-bit platform:
  1. use EFI Boot Services directly from Xen:
     a. jump into Xen code in multiboot2 protocol 32-bit mode,
     b. jump into Xen code in EFI 64-bit native platform mode,
  2. add EDD and MBR tags to multiboot2 protocol specification.

Solution 1a:
  - no major changes in GRUB2 are required but at least one
    minor fix should be applied (look above),
  - jump into Xen code in multiboot2 protocol 32-bit mode,
  - must switch back to EFI 64-bit native platform mode in Xen
    (switch processor to 64-bit mode and build identity page tables;
    former is quite simple but later could be quite difficult
    because we cannot overwrite EFI code, Xen code and modules
    code/data),
  - use EFI Boot Services from Xen to get EDD and MBR,
  - call ExitBootServices() from Xen code,
  - execute Xen code as usual.

Solution 1b:
  - add specification for multiboot2 protocol 64-bit mode;
    currently only 32-bit mode is specified and implemented,
  - implement this mode in GRUB2 and Xen,
  - use EFI calls/data and multiboot2 protocol tags as needed.

Solution 2:
  - add two new tags to multiboot2 protocol specification
    which will describe EDD and MBR,
  - GRUB2 could safely call ExitBootServices(); still there is
    open question how to use Secure Boot feature in connection
    with GRUB2; in theory in the future we could use SB stuff
    or GnuPG detached signatures; look here for more details:
    http://lists.xen.org/archives/html/xen-devel/2013-10/msg01823.html,
  - jump into and execute Xen code as usual.

These are rough ideas and I hope that we work out something which
could be quite quickly implemented.

Daniel

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