From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 4/4] xen/public: arm: rework the macro
 set_xen_guest_handle_raw
Date: Wed, 4 Nov 2015 14:54:57 +0000
Message-ID: <1446648897.6461.98.camel@citrix.com>
References: <1446228813-2593-1-git-send-email-julien.grall@citrix.com>
	<1446228813-2593-5-git-send-email-julien.grall@citrix.com>
	<alpine.DEB.2.02.1511021520190.15801@kaball.uk.xensource.com>
	<1446554124.10390.19.camel@citrix.com> <5638BE43.4080607@citrix.com>
	<1446561267.10390.48.camel@citrix.com> <5639E949.6020800@citrix.com>
	<1446636465.6461.70.camel@citrix.com> <5639EEB6.6040908@citrix.com>
	<1446647350.6461.89.camel@citrix.com> <563A1950.8050308@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=7432c2585=Ian.Campbell@citrix.com>)
	id 1ZtzSq-0002nc-AP
	for xen-devel@lists.xenproject.org; Wed, 04 Nov 2015 14:55:04 +0000
In-Reply-To: <563A1950.8050308@citrix.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: Julien Grall <julien.grall@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>, Jan Beulich <jbeulich@suse.com>, Tim Deegan <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

On Wed, 2015-11-04 at 14:42 +0000, Julien Grall wrote:
> On 04/11/15 14:29, Ian Campbell wrote:
> > > > > > This looses out on the arm32 hypervisor sanity checking that
> > > > > > the
> > > > > > padding
> > > > > > bytes are 0 (as required by the ABI) but TBH I haven't checked
> > > > > > that
> > > > > > the
> > > > > > current version has that property either.
> > > > > 
> > > > > It's done during the assignation by the compiler:
> > > > > 
> > > > > (hnd).q = (uint64_t)(uintptr_t)(val);
> > > > 
> > > > I meant on the reading side.
> > > 
> > > It's the responsibility of the caller to zero the padding. There is
> > > nothing to do on the reading side, the hypervisor will use "p" which
> > > will be the size of the natural pointer.
> > 
> > For a 32-bit Xen the check would be that a guest was not inadvertently
> > violating this rule, such a guest would crash if it was run on a 64-bit
> > hypervisor (which would see the non-zero padding as part of the
> > pointer),
> > by rejecting such cases on 32-bit Xen we avoid such guests becoming
> > established and therefore presenting a case for us to relax this rule
> > in
> > one way or another.
> 
> It would add overhead each time we want to copy to/from the guest memory.

I was simply commenting that the approach taken here might be removing such
a check _if_ it exists today, and as I said up front I'm not sure we have
such a check right now or not.

I'm not suggesting you add one as a new check, just that _if_ it already
exists then it being removed needs to be considered.

Ian.