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