From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: On Dom0 disaggregation Date: Thu, 12 Jan 2012 14:30:36 +0100 Message-ID: <4F0EE07C.2070603@invisiblethingslab.com> References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov> <4F0EB6ED.3030900@invisiblethingslab.com> <20120112104802.GA47092@ocelot.phlegethon.org> <4F0EC198.9050406@invisiblethingslab.com> <20120112121303.GE47092@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1464406276883005477==" Return-path: In-Reply-To: <20120112121303.GE47092@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) --===============1464406276883005477== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7A1A6172AC755654923F9A44" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A1A6172AC755654923F9A44 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/12/12 13:13, Tim Deegan wrote: > 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=3D1346278 , >>> 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. >=20 > Yep. That's what Xoar did (or, if you prefer, it moved all dom0's > components out and then got rid of it). >=20 >> When considering this task, one should answer >> the following questions: >> >> 1) Who manages the chipset (MCH)? >=20 > A driver domain that contains PCIback. It doesn't need general > privlege (e.g. for scheduler or memory operations). >=20 >> 2) Who manages the input (keyboard, mouse) >> 3) Who manages the output (GPU, specifically critical on client system= s) >> >> From the security point of view there is no point of isolating the >> entities that manage the above between each other, because a compromis= e >> of any of those entities leads to full system compromise (again, #3 >> applies to client systems). >=20 > #2 is really a client-only thing as well. Serial console input for > servers is owned directly by the hypervisor. >=20 >> 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). >=20 > Yes we could (and Xoar did). IIRC the only reason it needs privilege i= s > to map the rings and that can be sorted out by having the builder > pre-load a grant entry. >=20 >> So, we end up with a conclusion that there is no point separating thos= e >> 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? ;= ) >=20 > So you're saying that the PCIback domain (which owns the chipsets) migh= t > 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.=20 >=20 But the paper says the PCIBack is destroyed after init -- who manages the chipset (MCH, ICH, platform power management), then? Also, if I correctly interpret your architecture, then BlkBack VM must be trusted, as it has access to the disk, and thus can serve compromised fs/kernel/initramfs images to VMs, and also modify boot partition to load compromised Xen on the next boot (unless you use something like Intel TXT for Xen load). So, what's the reason of separating it from (the trusted) Xenstored VM? Unless the kernel/initramfs images (at least for PV domains) come from some trusted source, not from blkbackend? Then they could contain code to verify integrity of the fs served from blkbackend. Have you considered this in your architecture? Also, if this was a client system, where would you put user input/output handling? joanna. --------------enig7A1A6172AC755654923F9A44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPDuB8AAoJEDaIqHeRBUM07uIH/0gurG5pMd68qCsAFNW9sx9o cfFP8RQhX2WLmj7o0Qu5eylzozQNJpeca/Bup/tTXWh8Yj0buuy4BS36y5siAUde +rlZ9683amnZ0F/dx5pACR49b6RuPGmc0XkSsZJt/SfLVACYpaOABce9Ylu3uZgb YNVFGEGHNTIqFE4Dp9r6xU3IQF5dgxLO0wIN2mnHGkLNPRCDu7BBj59d7tAIgx+/ xlX/txzcHNWjbjCsSaoqmNYu2/KKWWKb3DK3EJFzHosQs6gv6/UKb0pYQ1FVSd2R JD8z7934UBK1QcAti1hifym/ah226FevdX6v4KU4wOJHhUl6wFw1OsyV9WzKk2E= =OaQD -----END PGP SIGNATURE----- --------------enig7A1A6172AC755654923F9A44-- --===============1464406276883005477== 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 --===============1464406276883005477==--