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
--
xen mailing list
xen@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/xen
