Re: [Xen Hackathon] EFI + GRUB2 + Xen

[Goswin von Brederlow]

On Thu, May 22, 2014 at 06:10:41PM +0200, Daniel Kiper wrote:
> 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.

Is there a MULTIBOOT2_TAG_TYPE_EFI that contains EFI infos? That
should be created or extended to contain all the infos.
 
> 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),

If EFI garantied to run with identity mapping? I.e. is creating
identity mapping enough or does one have to restore the original page
tables?

Building the page tables is simple if they are included in the rodata,
data or bss section. Don't dynamically allocate them. That way nothing
can get overwritten by accident.

Also couldn't grubs memory map point out regions with valuable data in
them?

>   - 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.

Years ago I proposed a patch to the multiboot2 specs to include AMD64
as additional architecture that would switch to 64bit before calling
the kernel and would understand 64bit elf format. Unfortunately nobody
cared enough to include it.

But maybe now someone does since it would solve (part of) the EFI
problem.

In the Multiboot header the "architecture" field should say '8' (the
next free one) saying 64-bit (long) mode of i386 aka amd64/x86_64.

Secondly I would add a new mbi_tag_types in the Multiboot information
request for efi_support. If present GRUB will add the EFI information
to the mbi and leave boot services open. If flags 'optional' is set to
'0' then GRUB must fail if not booting from EFI (usual not-optional
behaviour). If EFI information is not specifically requested then GRUB
will close EFI boot services and not pass EFI information along.

> Solution 2:
>   - add two new tags to multiboot2 protocol specification
>     which will describe EDD and MBR,
>   - GRUB2 could safely call ExitBootServices(); still there is

I'm not too familiar with EFI but can you get the boot services back
once they are exited? A kernel (maybe not xen) might need them.

>     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

I hope you will come up with a solution for 64bit support that works
for non-EFI and non-xen systems too.

MfG
        Goswin