From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: On Dom0 disaggregation (was: Re: [RFC PATCH 0/18] Xenstore stub domain) Date: Thu, 12 Jan 2012 12:18:48 +0100 Message-ID: <4F0EC198.9050406@invisiblethingslab.com> References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov> <4F0EB6ED.3030900@invisiblethingslab.com> <20120112104802.GA47092@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3507973325927486997==" Return-path: In-Reply-To: <20120112104802.GA47092@ocelot.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: Daniel De Graaf , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3507973325927486997== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig35F849397C618C67501DE8C7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35F849397C618C67501DE8C7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/12/12 11:48, 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 syste= m? >> 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...? >=20 > 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=3D1346278 , > http://tjd.phlegethon.org/words/sosp11-xoar.html) >=20 In order for this to make sense from security point of view, you would need to deprivilige Dom0. When considering this task, one should answer the following questions: 1) Who manages the chipset (MCH)? 2) Who manages the input (keyboard, mouse) 3) Who manages the output (GPU, specifically critical on client systems) =46rom 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). 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). 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? ;) (Sure, this "new Dom0" doesn't include net, USB, and perhaps even SATA drivers, but we already have been doing this on Qubes, except for moving out SATA/blkbackend from Dom0). joanna. --------------enig35F849397C618C67501DE8C7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPDsGYAAoJEDaIqHeRBUM0UI8IAIFfX9qU/P3IyCJ7KPdyExkG BEaKBUu0EUPhbYeFTRNW1U8T8C35efs4ae0ZrSVqHKGKSg0Sq/lX6m1okfbVWW9J Yrue/NYmFRTdIQWQVZusyf8doAhpN/WGlRtThjAzLWFUthe0Z3OX1lKf+ddwJZHW UHNAsTVZObm0U5VcUmkFafOrpQYypVDcDEb4plBO1OesztNP+tQpw/wGMAcg6bf2 Xqf25Z9UpP5jnTTuxfEvpYDWBpPsnioAwmgssSsVNBNalbu4Q8JbqFzqrjDviOjO d13kiVDub/4fJeBgvWB1Nvc/pJR/Pp3OQOFfdEHEO57oViJfDdAphS3OHU2bOA0= =Uysv -----END PGP SIGNATURE----- --------------enig35F849397C618C67501DE8C7-- --===============3507973325927486997== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============3507973325927486997==--