Re: [Xen-devel] On Dom0 disaggregation

[Tim Deegan <tim@xxxxxxx>]

At 14:30 +0100 on 12 Jan (1326378636), Joanna Rutkowska wrote:
> > So you're saying that the PCIback domain (which owns the chipsets) might
> > as well host Xenstore since either of them could hose the system.
> > Maybe so.  In Xoar we had two reasons not to do that:
> >  - in some configurations you could shut that domain down after boot
> >    (though tbh doing that leads to poor error handling!); and
> >  - we were doing other hardening of Xenstore that involved breaking it 
> >    up into more than one VM. 
> > 
> 
> But the paper says the PCIBack is destroyed after init -- who manages
> the chipset (MCH, ICH, platform power management), then?

Nobody.  Like I said, it's not ideal. :)

You don't have to destroy PCIBack -- you can keep it around to do those
things.  And if you do, it has a _much_ narrower interface to the rest
of the world than dom0 does.  It has no network access, and no direct
interface to customer (i.e. non-driver) VMs.  A malicious customer VM
must break at least one other system VM before it can attack it.

> Also, if I correctly interpret your architecture, then BlkBack VM must
> be trusted, as it has access to the disk, and thus can serve compromised
> fs/kernel/initramfs images to VMs, and also modify boot partition to
> load compromised Xen on the next boot (unless you use something like
> Intel TXT for Xen load). So, what's the reason of separating it from
> (the trusted) Xenstored VM?

Well, you can have multiple block driver domains, if you have multiple
HBAs, and arrange that two customers' data don't share a blkback.

And there are the usual reasons for driver domains.  For example you're
not tied to a particular OS for all your drivers.  And device-driver
crashes don't take out xenstore.

Trusted boot is orthogonal to the Xoar work.  We didn't go into it in
the paper but it's fairly obvious how it would fit in.  And once you've
got a TPM you could also use vTPMs to protect VMs' disk images.

> Also, if this was a client system, where would you put user input/output
> handling?

I'd probably make a console driver VM that owned the GPU and the USB
controller.  It might make sense for the toolstack (or at least the
parts that compose the display and demux the inputs) to live in that VM
too.  Or maybe it would be better to isolate those drivers; I haven't
given it a lot of thought. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel