Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

["Maliszewski, Richard L" <richard.l.maliszewski@xxxxxxxxx>]

I may be off-base, but when I was wading through the grub2 code earlier
this year, it looked to me like it was going to refuse to launch anything
via MB1 or MB2 if the current state was a secure boot launch.

--Richard

On 10/22/13 9:24 AM, "Vladimir 'φ-coder/phcoder' Serbinenko"
<phcoder@xxxxxxxxx> wrote:

>On 22.10.2013 18:01, Daniel Kiper wrote:
>> On Tue, Oct 22, 2013 at 03:42:42PM +0000, Woodhouse, David wrote:
>>> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>>>>
>>>> There are two problems with this:
>>>>
>>>> 1) The kernel will only boot if it's signed with a key in db, not a
>>>>key
>>>> in MOK.
>>>> 2) grub will read the kernel, but the kernel will have to read the
>>>> initramfs using EFI calls. That means your initramfs must be on a FAT
>>>> partition.
>>>>
>>>> If you're happy with those limitations then just use the chainloader
>>>> command. If you're not, use the linuxefi command.
>>>
>>> Well, we're talking about booting the Xen hypervisor aren't we?
>>>
>>> So yes, there are reasons the Linux kernel uses the 'boot stub' the way
>>> it does, but I'm not sure we advocate that Xen should emulate that in
>>> all its 'glory'?
>> 
>> Right, I think that sensible mixture of multiboot2 protocol (it is
>>needed
>> to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot
>>protocol
>> for it) with extension proposed by Vladimir and something similar to
>>linuxefi
>> command will solve our problem (I proposed it in my first email). Users
>>which
>> do not need SB may use upstream GRUB2 and others could use
>> 'multiboot2efi extension'.
>I think it's possible to handle secureboot with same multiboot2 base.
>Correct me if I'm wrong but secureboot doesn't specify format of
>signaatures, only that they should be present and checked.
>So why not to make that the only difference between secureboot-enabled
>and not-secureboot-enabled versions is that former enforces signatures
>even against user will. This will reduce the policy-charger patch to
>about 100 lines.
>The signature format to use can be discussed as well. My main problem
>with pe signatures as used for EFI is their apparent complexity but I
>haven't looked in them yet.
>> 
>> Daniel
>> 
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@xxxxxxx
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>> 
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel