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