WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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

Attachment: minios.xenbus.patch
Description: Binary data

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