From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH 3/3] evtchn/fifo: don't spin indefinitely when setting LINK Date: Wed, 06 Nov 2013 10:01:53 -0500 Message-ID: <527A59E1.7070002@oracle.com> References: <1383231791-4604-1-git-send-email-david.vrabel@citrix.com> <1383231791-4604-4-git-send-email-david.vrabel@citrix.com> <527A465A.2010806@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <527A465A.2010806@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: Keir Fraser , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 11/06/2013 08:38 AM, David Vrabel wrote: > On 31/10/13 15:03, David Vrabel wrote: >> From: David Vrabel >> >> 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