linux-kernel - Re: 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]

Message-Id: <52654A0602000078000FC611@nat28.tlf.novell.com>
Date:	Mon, 21 Oct 2013 14:36:38 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Daniel Kiper" <daniel.kiper@...cle.com>
Cc:	<ian.campbell@...rix.com>, <ross.philipson@...rix.com>,
	<stefano.stabellini@...citrix.com>, <grub-devel@....org>,
	<david.woodhouse@...el.com>, <richard.l.maliszewski@...el.com>,
	"xen-devel" <xen-devel@...ts.xenproject.org>,
	<boris.ostrovsky@...cle.com>, <konrad.wilk@...cle.com>,
	<pjones@...hat.com>, <linux-kernel@...r.kernel.org>, <keir@....org>
Subject: Re: EFI and multiboot2 devlopment work for Xen

>>> On 21.10.13 at 14:57, Daniel Kiper <daniel.kiper@...cle.com> wrote:

(Looking at the Cc list it's quite interesting that you copied a
whole lot of people, but not me as the maintainer of the EFI
bits in Xen.)

> Separate multiboot2efi module should be established. It should verify system
> kernel and all loaded modules using shim on EFI platforms with enabled 
> secure boot

Each involved component verifies only the next image. I.e. the
shim verifies the Xen image, and Xen verifies the Dom0 kernel
binary. The Dom0 kernel (assuming it to be Linux) will then be
responsible for dealing with its initrd. (One open question is how
Xen ought to deal with an eventual XSM module; I take it that
the CPUs themselves take care of the microcode blob.) This can't
be different because the shim provided verification protocol
assumes that it's being handed a PE image (hence the need for
Linux to package itself as a fake PE image), and hence can't be
used for verifying other than the Xen and Dom0 kernel binaries.

> At first I am going to prepare multiboot2 protocol implementation for Xen 
> (there
> is about 80% of code ready) with above mentioned workaround.

Is that really worthwhile as long as it's not clear whether ...

> Later I am going to work on multiboot2efi module.

... is going to be accepted?

> What do you think about that?
> Any comments, suggestions, objections?

The complications here make it pretty clear to me that the
GrUB2-less solution (or, if GruB2 absolutely has to be involved,
its chain loading capability) I have been advocating continues
to be the better (and, as said before, conceptually correct)
model.

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/