[Xen Hackathon] EFI + GRUB2 + Xen - minutes

[Daniel Kiper]

Hi,

Below you could find minutes taken by Konrad (thanks!) during
EFI + GRUB2 + Xen session which happened on Xen Hackathon.
I made some minor fixes/cleanups. Session was led by me.

Here you could find detailed description of the problem:
http://lists.xen.org/archives/html/xen-devel/2014-05/msg02928.html

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

EFI support written by Jan - but there is a requirement for GRUB2 loader
instead of loading an Xen EFI binary.

Working prototype exists but before we venture in that, lets start
with questions.

What Xen needs from an EFI platform: EFI T/F (tables/functions), ACPI, MMAP
(EFI memory map), VGA, EDD, MBR.

If you run Xen EFI on the platform it has all of that directly. However
GRUB2 it calls ExitBootServices which means you cannot get EDD or MBR
information. That is one problem.

Transition from GRUB2 -> Xen is 32-bit mode which is strictly specified
in the multiboot spec (and the source code). The EFI T/F are 64-bit mode
so this pointer might not be accessible - it is now, but might not be
in the future. GRUB2 drops to 32-bit because multiboot requires even though
EFI platform calls GRUB2 in 64-bit mode.

The reason this is a problem, is that to get EDD/MBR you must switch
to 64-bit mode - and must create new pagetables without over-writting any
existing ones.

The EFI memory map in GRUB2 has the reserved and runtime memory
map and the separation (loader data, boot data). Passed in through GRUB2
stock EFI via multiboot2 protocol - which can solve the rebuilding the
Xen pagetables.

EFI application - everything would need to done before start_xen.
In this situation (where we don't have the EFI T/F) we need to create
the identity pagetables for EFI. Low half is needed for the 1-1 page-tables.
With the EFI you can do it at the same time - low half for 1-1 page
tables and the high memory for the rest. This is solution 1a in Daniel's
email.

Solution 2, would be to extend the multiboot2, but the maintainer is
not responsive.

Or GRUB2 before passing ExitBootServices would require EDD and MBR
to extend the mulitboot. But that has the danger that anything there
is something in the future we would need to extend it.

If you use 'linuxefi', then everything is OK. If you use 'linux'
then ExitBootServices is. But we can't use it because it can only
do use one payload (initrd).

Things we need:
 - Don't call ExitBootServices (done)
 - Flag for launching in 64-bit mode. We can work with the 32-bit and recreate 
the
   pagetables.
 - Flag for entertain in standard EFI calling method.
 - Flag for separate entry point (ImageHandler).

However we cannot call ExitBootServices from Xen because ImageHandler
is not passed.

What we need is to combine multiboot2 and EFI.

SecureBoot - the shim can only sit between two EFI images (shim is
an EFI image). What the shim calls must be EFI image too.

We don't know the constraint of what the GRUB2 has to call EFI with
SecureBoot enabled. We can move multiboot header as it does not have to
be in the 512 bytes.

New multiboot2-EFI which looks like EFI and can do extra things - pass
in the parameters. But the shim does not know the multiboot2-EFI protocol.

If this protocol is installed in the shim.

GRUB2 calls the EFI with the multiboot2 protocol.

The SecureBoot requires each party to verify the next executable. Meaning
GRUB2 needs to verify xen.gz. Xen.gz needs to verify kernel.gz, etc.

GRUB2 is the first on the chain. Load shim, Xen, dom0, initrd, microcode.

In the distro acceptance we don't want to diverge.

The multiboot2 would be passed on the EFI. Only the ImageHandler and system
tables get passed. Can each system table be expanded - yes.

Xen's job to check the kernel. The multiboot protocol checks. The multiboot2
has to do it.

EFI -> shim -> grub -> calls back to shim to validate -> calls Linux

In this scenario we can use the shim. We need ImageHandler.

---
We would to need to detect whether we are loaded via EFI or
multiboot2.
--

Ian suggested flags. We need GRUB2 to call with standard EFI (as specified).
Call that efi_entry point in the multboot2 as an normal EFI application.
(Xen.EFI?)

Can't do with xen.gz because SecureBoot won't work in there.

And Xen can look in its multiboot2 header to figure this out?
And the extra flag and the offset (handover).

Codewise the EFI code needs to be split.

ImageHandler is only needed for ExitBootServices.

We want the same prototype - efi_main. The code (EFI Xen code)
would check the multiboot structure if it has been modified.

This has the benefit that we can interrogate the EFI system table
to interrogate this.
--

Xen already has the signature checking of its payload!

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

I am going to prepare solution based on above findings
and post relevant patches for GRUB2 and Xen.

Daniel