Re: [RFC PATCH 0/18] Xenstore stub domain

[Ian Campbell <Ian.Campbell@citrix.com>]

On Thu, 2012-01-12 at 11:35 +0000, Joanna Rutkowska wrote:
> On 01/12/12 12:27, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> >> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> >>> Daniel,
> >>>
> >>> Can you explain what is the rationale for moving the xenstored into a
> >>> stubdom? After all, if an attacker is able to compromise the xenstored,
> >>> there should be many ways now how to compromise other VMs in the system?
> >>> And it shouldn't matter whether the xenstored is in stubdom or whether
> >>> in Dom0. E.g. the attacker might redirect the block fronts to us some
> >>> false block backends, so that the VMs get compromised fs. One could
> >>> probably think of other attacks as well...?
> >>
> >> 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)
> > 
> > Also by isolating components you gain the ability to restart them
> > independently. Since xenstored is one of (the only?) dom0 component
> > which cannot be trivially restarted so putting it in a separate domain
> > means you can restart dom0.
> > 
> 
> But why would anybody want to restart Dom0, in the first place?

To patch the kernel?

Ian.