linux-kernel - Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Oct 2013 09:32:30 +0100
From:	Ian Campbell <ian.campbell@...rix.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.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 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
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.

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.

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

Ian.

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