From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 3/3] [GSOC14] FIX:- Race condition
 between initializing shared ring and mempaging.
Date: Wed, 23 Jul 2014 11:32:52 +0100
Message-ID: <53CF8F54.6090008@citrix.com>
References: <1402942851-12538-1-git-send-email-myselfdushyantbehl@gmail.com>		<1402942851-12538-4-git-send-email-myselfdushyantbehl@gmail.com>		<1403865212.25894.11.camel@kazak.uk.xensource.com>		<CAHF350Lqv03cC_cKX818D9CfxmRvpr8JjZeOu8DgEsmHfU0vSQ@mail.gmail.com>		<CADzFZPu90JFxAfc0EgZO5H6FtYYzB2xdYASHq0F7YU8M-H+v4Q@mail.gmail.com>		<53CCD6ED.3020303@citrix.com>	
	<CADzFZPvedgLknUzsSkBw_3Va7uqmqSRVfmtPBJ80No2tLqCgLg@mail.gmail.com>	
	<53CD2670.50704@citrix.com>
	<1406110440.17026.1.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1406110440.17026.1.camel@kazak.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: David Scott <dave.scott@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Xen Devel <xen-devel@lists.xen.org>, Andres Lagar Cavilla <andres@lagarcavilla.org>, Dushyant Behl <myselfdushyantbehl@gmail.com>
List-Id: xen-devel@lists.xenproject.org

On 23/07/14 11:14, Ian Campbell wrote:
> On Mon, 2014-07-21 at 15:40 +0100, Andrew Cooper wrote:
>
>>> Note that the XSA commmit, 6ae2df93c27, does exactly that. Enable
>>> paging/access/sharing, and only after that decrease reservation (and
>>> after that unpause). So the window is open ... methinks?
>> No - it does a domain pause around this set of critical operations, so
>> the guest is guaranteed not to be running, and therefore cannot
>> interfere.
> Shouldn't there be a memset in here somewhere? To clear out any bogus
> material in the ring? (maybe the caller of this code always clears the
> ring itself, I didn't check that)
>
> Ian.
>

Erm.  There probably should be.  Xen sets up the ring frontend
correctly, but nothing I can spot cleans up any stale backend state
which was preexisting in the page.

It seems possible for a guest can map the affected pages and leave some
crafted backend replies which will be picked up as soon as mem_events
are enabled.  Combined with the lack of validation of responses in Xen,
this is quite bad.

~Andrew