Re: [Xen-devel] On Dom0 disaggregation

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

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=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.
> 
> Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
> components out and then got rid of it).
> 
>> When considering this task, one should answer
>> the following questions:
>>
>> 1) Who manages the chipset (MCH)?
> 
> A driver domain that contains PCIback.  It doesn't need general
> privlege (e.g. for scheduler or memory operations).
> 
>> 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).
> 
> #2 is really a client-only thing as well.  Serial console input for
> servers is owned directly by the hypervisor.
> 
>> 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).
> 
> Yes we could (and Xoar did).  IIRC the only reason it needs privilege is
> to map the rings and that can be sorted out by having the builder
> pre-load a grant entry.
> 
>> 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? ;)
> 
> So you're saying that the PCIback domain (which owns the chipsets) might
> 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. 
> 

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.

Attachment: signature.asc
Description: OpenPGP digital signature

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