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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-11-26 at 18:16 +0000, Andrew Cooper wrote:
> On 26/11/12 17:57, George Dunlap wrote:
> > So while doing a bit of investigation into a request that we have
> > instructions for how to sign a Xen binary, I came across a related
> > pair of questions.  If we boot from a signed Xen binary, then:
> > 1. Will Xen then successfully boot a signed dom0 kernel / initrd?
> > 2. Will Xen fail to boot an unsigned dom0 kernel / initrd?
> >
> > I think if Xen is signed, then ideally we want both 1 and 2 to be
> > true, right?  Does UEFI provide a way to check the signature of
> > files?  Does it happen automatically, or would we need to add extra
> > support?  Or would we need to embed a public key within the Xen binary
> > and have Xen check the signatures of files that it reads?
> >
> >  -George
> 
> The problem is deeper than that.
> 
> 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.
> 
> 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.

AIUI Restricted Boot doesn't really concern itself with the integrity of
the system post boot, just with the integrity of the bits which are
being booted. I think this extends to booting dom0 but anything relating
to booting guests could reasonably be considered to be handled
separately.

Given that it's very possible that the hypervisor could lock down even
dom0 from being able to make calls which would allow the firmware to be
subverted (i.e. access to I/O ports or MMIO regions which would allow
the BIOS to be reflashed or whatever), at which point dom0 root user and
toolstack becomes irrelevant.

That probably involves some sort of black/whitelisting scheme for I/O
ports and such which is pretty tedious but not overwhelming I don't
think.

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

It would need to be able to subvert the bootloader and system firmware
or something, which seems like a bit of a stretch.

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

Ian.


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