Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain

[Vasiliy Tolstov <v.tolstov@xxxxxxxxx>]

2012/1/12 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Thu, 2012-01-12 at 10:48 +0000, 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)
>
> Also by isolating components you gain the ability to restart them
> independently. Since xenstored is one of (the only?) dom0 component
> which cannot be trivially restarted so putting it in a separate domain
> means you can restart dom0.
>
>

Is that possible now (or in some feature) to restart xenstore domain
and not loose watches? Now if i save all contents in xenstore and
restart xenstored i'm loosing all watches and domU's not able to work
correctly...

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@xxxxxxxxx
jabber: vase@xxxxxxxxx

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