Message-ID: <20131023131348.GA23898@phenom.dumpdata.com>
Date:	Wed, 23 Oct 2013 09:13:48 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Ian Campbell <ian.campbell@...rix.com>
Cc:	grub-devel@....org, keir@....org, david.woodhouse@...el.com,
	stefano.stabellini@...citrix.com,
	Daniel Kiper <daniel.kiper@...cle.com>,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xen.org,
	Jan Beulich <JBeulich@...e.com>,
	Peter Jones <pjones@...hat.com>, ross.philipson@...rix.com,
	boris.ostrovsky@...cle.com, richard.l.maliszewski@...el.com,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

On Wed, Oct 23, 2013 at 09:32:30AM +0100, Ian Campbell wrote:
> On Tue, 2013-10-22 at 12:26 -0400, Konrad Rzeszutek Wilk wrote:
> > It can (at least in Linux). There are two entry points in the Linux kernel
> > and - one when it is launched from 'linuxefi' (See efi_stub_entry in 
> > arch/x86/boot/compressed/head_64.S), the other when it is launched
> > from an EFI shell - see efi_pe_entry in arch/x86/boot/compressed/head_64.S.
> 
> 
> Yes, it seems I was confused and spreading misinformation. Sorry!
> 
> Matthew explained this stuff to me yesterday, let me see if I can
> regurgitate it. Hopefully Matthew can crrect the inevitable mistakes...
> 
> A kernel binary built with EFI stub support has three entry points:
> 
>       * The traditional real mode "zImage" entry point
>       * The standard PE/COFF entry point
>       * A "Linux EFI" PE/COFF entry point
> 
> I think we can safely ignore the first of these for the purposes of this
> conversation. I'm also going to ignore SB initially and cover it
> separately at the end.
> 
> The second (standard PE/COFF entry point) can be launched using the UEFI
> chainloader call. AIUI this should work with xen.efi today. There are
> some limitations however, firstly there is no way to pass additional
> blobs and so the launched image must load e.g. dom0 and initrd itself,
> which Linux does by processing the initrd= option in the command line
> and using UEFI functionality to load the blobs from disk. Xen does by
> reading its own config file and loading dom0 + initrd based on that. I
> assume this means that chainload doesn't call ExitBootServices (anyone
> can confirm?). Another limitation of this is that the UEFI functionality

Confirmed.

> to load stuff from disk can only read from FAT partitions.  It's not
> clear to me if this mechanism limits only the loading of additional
> blobs from FAT or if that applies to the kernel image itself. In reality
> the blob and the kernel are usually stored in the same directory anyhow.
> 
> Is there a second method which can load standard PE/COFF images i.e.
> some sort of "boot a kernel" method which calls ExitBootServices etc?
> Even if this exists I don't think we can/want to use it.

None that I can find in GRUB2 - either upstream or Fedora's version.

> 
> The third ("Linux EFI" PE/COFF entry) is launched with the "efilinux"
> patch to grub. This does not call ExitBootServices and also passes an
> additional struct to the kernel which contains mostly (exactly? == is
> the same struct) the same stuff as the traditional 16-bit entry point
> would construct and pass to the 32-bit kernel. The EFI stub can also use
> UEFI calls to get most (all?) of the same info. There was some related
> madness about how the framebuffer is detected. Unlike the chainload
> mechanism efilinux does not expect or provide PE/COFF relocation. The
> kernel is PIC on entry so no relocations are actually needed. In theory
> the Linux EFI stub could instead have included a NULL relocation table
> but doesn't. (I expect Xen is in the same boat WRT relocations). I think
> this method also provides a mechanism to provide a blob (AKA the initrd)
> to the kernel, which means it can be loaded from any filesystem which
> grub understands (not just FAT). There is only one which is a not
> sufficient for Xen.

Correct. Especially as we might have many binary blobs - microcode blob,
XSM blob, whoknowswhatblob, etc.
> 
> >From a SB point of view the major difference between chainload and
> linuxefi is that chainload can only validate signatures against the UEFI
> "core" key db (maintained by UEFI) while linuxefi can also use keys from
> MOK db ("Machine Operator Key", which is a second DB provided and
> maintained by "shim"). Michael was saying elsewhere in this thread that
> SuSE at least have a patch which allow the chainload mechanism to use
> MOK as well.
> 
> I hope that is an accurate braindump of what Matthew explained to me
> yesterday, mistakes are naturally all mine ;-)
> 
> Am I correct that xen.efi today can be loaded from grub today using the
> chainload command? Whereupon it will parse the xen.cfg and load the dom0
> kernel and load things from FAT etc and everything just works. IOW
>         UEFI -> chainload(Xen)
> and
>         UEFI -> chainload(grub) -> chainload(Xen)
> work equivalently from the POV of Xen?

Yes. However it does require the user to know the magic values in the Xen
configuration file and setup the chainload stanze correctly. That means
if a user wishes to modify some of the bootup options they have to modify
the Xen configuration file. No runtime changes.

>From a distro standpoint the FAT part is painfull - as the common mechanism
for the /boot directory is to have it in ext2/ext3. But I presume you can
have _two_ boot partitions with GPT - one FAT and one ext2 and the tool
(dracut?) can push the images/config changes in both partitions.

Hence the idea of expanding GRUB2 to have an evercompassing multiboot2
protocol that will carry all the EFI bits  and allow multiple
seperate payloads will require:

 - not make an ExitBootServices call - which it does right now in the Solaris
   GRUB2 case and in the Fedora GRUB2 case.
 - Do the signature verification (hand-waving which one - probably both).
 - Pack the right bits in the multiboot2 structure.

That will also require from the Xen side to:
 - support parsing multiboot2 structure

And on the dracut side to create a new stanze that will use multiboot2 for
Xen.efi.

Easy :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists