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]

Date:	Mon, 21 Oct 2013 10:23:47 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	Daniel Kiper <daniel.kiper@...cle.com>, 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, 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:
> 
> (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.)

I see this:

From: Daniel Kiper <daniel.kiper@...cle.com>
To: boris.ostrovsky@...cle.com, david.woodhouse@...el.com,
        ian.campbell@...rix.com, jbeulich@...e.com, keir@....org,


You are on the 'To' instead of the 'CC'. That should make the email
arrive at your mailbox much quicker than through the mailing list?

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

However my understanding is that the general distro approach is
to use GRUB2 and I think we want to follow the mainstream on this.
Which means using GRUB2 and making sense of the myrid of patches
that each distro has.
--
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/