On Mon, Oct 21, 2013 at 02:36:38PM +0100, Jan Beulich wrote:
> >>> On 21.10.13 at 14:57, Daniel Kiper <daniel.ki...@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.ki...@oracle.com>
To: boris.ostrov...@oracle.com, david.woodho...@intel.com,
ian.campb...@citrix.com, jbeul...@suse.com, k...@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
