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