From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC PATCH 0/18] Xenstore stub domain Date: Thu, 12 Jan 2012 10:48:02 +0000 Message-ID: <20120112104802.GA47092@ocelot.phlegethon.org> References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov> <4F0EB6ED.3030900@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Joanna Rutkowska Cc: Daniel De Graaf , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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) Tim.