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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

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
> > terminate.
> >
> > Fixing this requires a minor change to the ABI, which is documented in
> > draft G of the design.
> >
> > http://xenbits.xen.org/people/dvrabel/event-channels-G.pdf
> >
> > 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
> > transition.
> >
> > 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
> > event.
> 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?

-boris

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel