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/
Home Products Support Community News


RE: [Xen-users] Re: malicious paravirtualized guests: securityandisolati

To: <echo@xxxxxxxxxxxx>
Subject: RE: [Xen-users] Re: malicious paravirtualized guests: securityandisolation
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Wed, 12 Nov 2008 13:44:06 +1100
Cc: Vasiliy Baranov <vasiliy.baranov@xxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 11 Nov 2008 18:44:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1226457369.5407.250.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <e4a2b0250811060515y6a898342u372768672e7365a@xxxxxxxxxxxxxx> <e4a2b0250811110635sfd631f8j34bde29d442a436c@xxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0154FB62@trantor> <1226457369.5407.250.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclEb490MdKsBs68RzuE1eCoQBv37gAAGX5g
Thread-topic: [Xen-users] Re: malicious paravirtualized guests: securityandisolation
> > Is there a limit on the amount of data you can write to the
> > Overflowing some limit in xenstore could be one method of causing a
> > crash.
> That's funny, I was just trying to find where these were set when
> xenstored is started:
>  --entry-nb <nb>     limit the number of entries per domain,
>  --entry-size <size> limit the size of entry per domain, and
>  --entry-watch <nb>  limit the number of watches per domain,
>  --transaction <nb>  limit the number of transaction allowed per
> So if the number of entries per domain (plus size per entry) can be
> limited .. it seems that at least --entry-size is not being enforced?
> If it were, the only way to overflow the store would be from dom-0,
> creating infinite domain entries @ xx bytes each until it exploded.
> Argh, I wish I was better with Python.

When testing save/restore under GPLPV, I created some scripts which do
save + restore on a loop and left them running for days. Domain id's in
the thousands were common during those tests.

It appears that in some DomU failure cases, xenstore entries are not
being cleaned up properly. With enough cruft in there, xenstore
operations start to take a loooong time... operatons that should take
seconds were taking minutes.

A reboot fixed it up of course, but it's not really ideal. That was
under 3.1.x though so those leaks may have been fixed since then.

It sounds like someone has at least thought about per-domain xenstore
limits though, which is encouraging.


Xen-users mailing list