From mboxrd@z Thu Jan  1 00:00:00 1970
From: Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH linux-2.6.18] xen: mark pvscsi frontend
 request consumed only after last read
Date: Fri, 30 Jan 2015 15:40:54 +0100
Message-ID: <54CB97F6.5070409@suse.com>
References: <1422625911-29988-1-git-send-email-jgross@suse.com>	
	<54CBA1CA020000780005B5A0@mail.emea.novell.com>
	<54CBA41E020000780005B5D7@suse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jgross@suse.com>) id 1YHCkk-0002Sf-Fh
	for xen-devel@lists.xenproject.org; Fri, 30 Jan 2015 14:40:58 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])
	by mx2.suse.de (Postfix) with ESMTP id D7FE0AC16
	for <xen-devel@lists.xenproject.org>;
	Fri, 30 Jan 2015 14:40:55 +0000 (UTC)
In-Reply-To: <54CBA41E020000780005B5D7@suse.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: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On 01/30/2015 03:32 PM, Jan Beulich wrote:
>>>> On 30.01.15 at 15:22, <JBeulich@suse.com> wrote:
>>>>> On 30.01.15 at 14:51, <"jgross@suse.com".non-mime.internet> wrote:
>>> A request in the ring buffer mustn't be read after it has been marked
>>> as consumed. Otherwise it might already have been reused by the
>>> frontend without violating the ring protocol.
>>>
>>> To avoid inconsistencies in the backend only work on a private copy
>>> of the request. This will ensure a malicious guest not being able to
>>> bypass consistency checks of the backend by modifying an active
>>> request.
>>
>> I'm not convinced we need this in this version of the driver: c/s
>> 590:c4134d1a3e3f took care of reading each ring_req field just
>> once.
>
> I should have clarified that I didn't mean we don't need to change
> anything here: We should still move down the point where the
> ring slot gets accounted as consumed.

My solution is more robust, I think. You don't have to be careful not
to introduce another double read somewhere.

Juergen