[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
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. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |