Re: [Xen-devel] On Dom0 disaggregation (was: Re: [RFC PATCH 0/18] Xenstore stub domain)

[Tim Deegan <tim@xxxxxxx>]

At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
> On 01/12/12 11:48, Tim Deegan wrote:
> > I think the point is to protect xenstore from dom0, not dom0 from
> > xenstore.  With stub-xenstore and driver domains, only the domain
> > builder and PCIback need to have any privilege, and they can be moved
> > out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> > http://tjd.phlegethon.org/words/sosp11-xoar.html)
> 
> In order for this to make sense from security point of view, you would
> need to deprivilige Dom0.

Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
components out and then got rid of it).

> When considering this task, one should answer
> the following questions:
> 
> 1) Who manages the chipset (MCH)?

A driver domain that contains PCIback.  It doesn't need general
privlege (e.g. for scheduler or memory operations).

> 2) Who manages the input (keyboard, mouse)
> 3) Who manages the output (GPU, specifically critical on client systems)
> 
> From the security point of view there is no point of isolating the
> entities that manage the above between each other, because a compromise
> of any of those entities leads to full system compromise (again, #3
> applies to client systems).

#2 is really a client-only thing as well.  Serial console input for
servers is owned directly by the hypervisor.

> Now, as you pointed out, we shall probably add another bullet to the
> list, which is:
> 
> 4) the xenstored
> 
> (although I'm not 100% if we couldn't somehow deprivilige xenstored).

Yes we could (and Xoar did).  IIRC the only reason it needs privilege is
to map the rings and that can be sorted out by having the builder
pre-load a grant entry.

> So, we end up with a conclusion that there is no point separating those
> 4 functionalists between each other, and so it only make sense to host
> them in the same domain. How about we call this domain "Dom0", then? ;)

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. 

Cheers,

Tim.

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