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 17:14:17 +0100
From:	"Jan Beulich" <jbeulich@...e.com>
To:	<ian.campbell@...rix.com>, <konrad.wilk@...cle.com>
Cc:	<ross.philipson@...rix.com>, <stefano.stabellini@...citrix.com>,
	<grub-devel@....org>, <david.woodhouse@...el.com>,
	<richard.l.maliszewski@...el.com>, <xen-devel@...ts.xen.org>,
	<boris.ostrovsky@...cle.com>, <daniel.kiper@...cle.com>,
	<pjones@...hat.com>, <mjg59@...f.ucam.org>,
	<linux-kernel@...r.kernel.org>, <keir@....org>
Subject: Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

>>> Ian Campbell <ian.campbell@...rix.com> 10/23/13 10:32 AM >>>
>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.

Again that's only a pseudo limitation: Rather than implementing support
for other file systems in GrUB, it should be implemented as EFI module.
Then any subsequent EFI binary would benefit from this. (Obviously, as
a half hearted intermediate solution, GrUB - which iiuc stays in memory
after transferring control - could export its file system support to its
descendants).

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

Only the additional blobs would be affected.

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

No, Xen definitely needs its relocations processed.

Jan

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