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

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



>>> On 20.11.13 at 16:19, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> On 12/11/13 11:38, 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
>> guest is trying to link a new event.  The cmpxchg() in
>> evtchn_fifo_set_link() will repeatedly fail and the loop may never
>> terminate.
> 
> This was fixed by introducing the BUSY bit (see below), but I wonder if
> another solution would be better.
> 
> The MASKED bits could all be moved into a separate bit array, guest
> writes to set/clear the MASKED bit would never conflict with Xen
> updating the main event word.  The cmpxchg() loop is then trivially
> bounded as the only valid writes by the guest are clear PENDING and
> clear LINKED & LINK.
> 
> The masked array could be either:
> 
> 1. In the same page as the event array.  This would waste a big chunk of
> the event array page though, Doubling the memory requirements.
> 
> 2. Have a separate set of pages.  EVTCHNOP_expand_array would be
> extended to supply the GFN for the array page where necessary. For 2^17
> events, 4 additional pages would be required for this masked array.

Further splitting up the necessary pages seems to make things more
complex than necessary. I'd stay with the various control bits all
grouped together.

Jan


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


 


Rackspace

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