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,
> 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
> 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
> 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.
xen mailing list