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: <20131021183906.GB3626@debian70-amd64.local.net-space.pl>
Date:	Mon, 21 Oct 2013 20:39:06 +0200
From:	Daniel Kiper <daniel.kiper@...cle.com>
To:	Jan Beulich <JBeulich@...e.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 Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
> >>> On 21.10.13 at 14:57, Daniel Kiper <daniel.kiper@...cle.com> wrote:

[...]

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

Currently Linux Kernel is only verified. Sorry, my fault.
As I know Matthew Garrett would like to verify Linux Kernel
modules too. However, I do not know details now. I think that
we should take into account his work.

> Xen ought to deal with an eventual XSM module; I take it that

Could you tell me more about that? What issues do you expect here?

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

It is only proposal. I am not going to continue work until we agree all details.

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

In general I agree but real life is more complicated (sadly). EFI boot loader
is not so flexible as GRUB2. Additionally, its configuration differs from
platform to platform. I do not mention that if you would like to change EFI
boot loader configuration from EFI platform configuration menu it is at least
onerous. Until all above mentioned issues (and others) will be fixed I do not
expect that everybody will use EFI boot loader as a standard way for system
loading. Probably it will happen later than sooner (if at all). So I think we
should find right solution for that problem instead of ignoring it.

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