[Fedora-xen] Xen, Fedora, and UEFI Secure Boot

[M A Young]

On Tue, 17 Jul 2012, Konrad Rzeszutek Wilk wrote:

> On Tue, Jul 17, 2012 at 03:45:02PM +0200, Dario Faggioli wrote:
>> On Sat, 2012-07-14 at 12:50 +0100, M A Young wrote:
>>> I contacted the people behind the the Fedora Seure Boot feature and got
>>> the following responses, from Peter Jones:
>>>
>> Wow, cool, thanks a lot!
>>
>>> Okay, to be honest I don't remember much about Xen's layout - dom0 is the
>>> management kernel the hypervisor starts? So, depending on how xen works,
>>> there
>>> are probably more things that need to be done in the hypervisor than in
>>> the
>>> kernel, because the hypervisor is the part that does most physical memory
>>> accesses, and that's where there's a worry about faking SB=0 and launching
>>> windows.
>>>
>>> At the very least, the hypervisor will a) need to be an efi binary, and b)
>>> need to be signed with the fedora kernel-signing key.
>>> It may also need to be
>>> audited for any command line options that allow physical memory access or
>>> other similar things, analogous to Matthew's kernel patch for linux.
>>>
>> As others have said, all the above should or will be fine, I guess.
>>
>> The only thing that comes to my mind is PCI passthrough, as it probably
>> could be thought at something allowing physical memory accesses... Or is
>> the control Xen/qemu provides over it sufficient? (Again, I think the
>> same could apply to KVM, right?).
>
> Right, and also kexec for example. There is code loaded from userspace
> binary into the kernel to deal with a crashed kernel. Its called
> purgatory code.
>
> What I am not clear is how far the "chain of trust" needs to go - b/c
> this also would imply module signing - which is right now _not_ in the
> upstream kernel.

The rawhide kernels have a big modsign patch (plus a fix) which seems to 
be from the modsign repo
http://git.kernel.org/?p=linux/kernel/git/dhowells/linux-modsign.git;a=summary

 	Michael Young