[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?


Attachment: minios.xenbus.patch
Description: Binary data

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.