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=su...
Michael Young