On Dom0 disaggregation (was: Re: [RFC PATCH 0/18] Xenstore stub domain)

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2123 bytes --]

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 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)
> 

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)

From 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.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel