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

Reply via email to