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

Re: [Xen-devel] [PATCH 3/3] evtchn/fifo: don't spin indefinitely when setting LINK

On 11/06/2013 08:38 AM, David Vrabel wrote:
On 31/10/13 15:03, David Vrabel wrote:
From: David Vrabel <david.vrabel@xxxxxxxxxx>

A malicious or buggy guest can cause another domain to spin
indefinitely by repeatedly writing to an event word when the other
domain is trying to link a new event.  The cmpxchg() in
evtchn_fifo_set_link() will repeatedly fail and the loop may never

Fixing this requires a minor change to the ABI, which is documented in
draft G of the design.


Since a well-behaved guest only makes a limited set of state changes,
the loop can terminate early if the guest makes an invalid state

The guest may:

- clear LINKED and link
- clear PENDING
- set MASKED
- clear MASKED

It is valid for the guest to mask and unmask an event at any time so
we specify that it is not valid for a guest to clear MASKED if the
event is the tail of a queue (i.e., LINKED is set and LINK is clear).
Instead, the guest must make an EVCHNOP_unmask hypercall to unmask the
Given the non-obvious locking required for this to be safe and the
overhead of the guest having to do a unmask hypercall more often.  I
think I will fix this differently.

A new BUSY bit is added to the event word.  Xen sets BUSY prior to
updating the LINK field and then clears it when the LINK field is set.

When the guest unmasks an event it must spin waiting for BUSY to clear
before it clears the MASKED bit.  It then need only do the unmask
hypercall if the event is pending (as before).

Draft H and v3 of this series to follow.

Will there be a new Linux series as well?


Xen-devel mailing list



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