Re: [Xen-devel] Xen.efi and secure boot

[George Dunlap <dunlapg@xxxxxxxxx>]

On Mon, Nov 26, 2012 at 6:16 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

The idea of secure boot is that only signed/verified code can perform
privileged operations.  One can argue as to exactly where this boundary
lies, but in the native case, it contains any kernel level code.
Userspace uses the kernel API/ABI subject to the permissions checks
present and (assuming no security holes), everyone is happy.

Different people have different opinions on this.  Fedora are signing all the way down to modules, but not user-space; as a result, IIUC, they are ruling out third-party or out-of-tree drivers.  Ubuntu are not signing modules AIUI, so in theory someone could install a rootkit; but they think that it's likely any local attacker is going to be able to attack the kernel anyway; on the balance having third-party drivers is more important to them.

Nonetheless, Ubuntu are still signing kernels, so that the kernel can still do some of the "boot mode" UEFI operations. (Not sure the correct term here.)  The idea is that the kernel will disable the "boot mode" UEFI operations before it loads any kernel modules.  Someone booting Xen directly from EFI may want to do the same thing.

 -George
 

In the Xen case, Xen will happily accept any privileged hypercalls from
dom0.  So you could argue that anything able to make ioctls against
/dev/xen/privcmd (and friends) would need to be within the signed code.
This is the entire toolstack, and all root processes.

Furthermore, cross-domain systems like xenbus/xenstore would also need
to be signed.  Imagine the carnage a malicious xenstored could cause!

I am struggling to think of a way of getting secure boot working
correctly without signing all of dom0.

--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel