Re: [PATCH] Re: [Xen-devel] Re: Xen bug 647: Creation of Mini-OS domain causes certain xm commandsto hang

[Grzegorz Milos <gm281@xxxxxxxxx>]

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

Attachment: minios.xenbus.patch
Description: Binary data

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