lkml.org 
[lkml]   [2013]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@oracle.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@oracle.com>
To: boris.ostrovsky@oracle.com, david.woodhouse@intel.com,
ian.campbell@citrix.com, jbeulich@suse.com, keir@xen.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.


\
 
 \ /
  Last update: 2013-10-21 17:01    [W:0.141 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site