| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [PATCH] Re: [Xen-devel] Re: Xen bug 647: Creation of Mini-OS domain
It looks like this patch only updates MiniOS - does this mean that
broken (or malicious...) guests can still hang the control server, or
has that been fixed independently?
Further tests revealed that the problem has not gone away
completely (although it seems to be happening more sporadically).
If Mini-OS does not initialise XenBus (if you remove xenbus_init()
call from kernel.c) the problem will not appear at all. So far I
have not been able to pinpoint the root cause of the problem
though. Maybe somebody more familiar with XenStore will be able to
help.
The patch certainly does not break anything though (this is mostly
for Keir's attention).
I'll get back to you if I find anything more.
Ok, found the cause:
MiniOS does test_xenbus soon after booting up. This in turn tries to
write to some file under device/vif/0/. XenStrore wil create device/
vif/0 directory to make the write possible even if no network
interfaces are defined. This confuses Xend as it expects to find a
backend corresponding to the bogus frontend. Clearly MiniOS induces
the incorrect behaviour but it's more of Xend bug.
To answer your question Muli - yes, it's possible for broken/
malicious guest to hang the control server.
I'm attaching a simple patch for MiniOS that disables the execution
of test_xenbus (but removing the writes would do as well).
Keir could you apply please?
Cheers
Gregor
minios.xenbus.patch
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home