On Sat, Jul 14, 2012 at 12:50:35PM +0100, M A Young wrote:
> I contacted the people behind the the Fedora Seure Boot feature and
> got the following responses, from Peter Jones:

Thanks for doing this!

> 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.
> We're still working out with rel-eng how getting things signed with
> that is
> going to work. I don't think there's really any necessity that it's
> announced
> in a proper Feature, but if you feel like going that way, that's fine too.
> and from Matthew Garrett:
> Right. We can conceivably sign Xen as long as it's an EFI binary, but
> I'd expect that it would have to enforce secure boot itself using the
> host databases.
> ------
> So we need to get xen working with EFI, to lock xen down so it can't
> be used to get around Secure Boot, and probably need to do some
> enforcement of secure boot as well.

I think you already know this, but Suse guys (Jan) made xen.efi working,
the patches are in xen-unstable (so in upcoming Xen 4.2), and they've
backported the efi patches to Xen 4.1 in SLES11SP2, and also 
Suse's (traditional) Linux 3.0 dom0 kernel has some patches for EFI.

-- Pasi

xen mailing list

Reply via email to