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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 11/06/2013 08:38 AM, David Vrabel wrote:
> On 31/10/13 15:03, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> 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