From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen: arm: fully implement multicall interface. Date: Fri, 28 Mar 2014 15:01:18 +0000 Message-ID: <53358EBE.4060303@linaro.org> References: <1396015649-5886-1-git-send-email-ian.campbell@citrix.com> <1396017905.8670.71.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1396017905.8670.71.camel@kazak.uk.xensource.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: Ian Campbell Cc: keir@xen.org, stefano.stabellini@eu.citrix.com, George Dunlap , tim@xen.org, xen-devel@lists.xen.org, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On 03/28/2014 02:45 PM, Ian Campbell wrote: > My feeling is that any (exploitable or otherwise) issue due to this > would be due to lack of proper error checking in the hypercall, and > would be equally accessible by a 64-bit guest. I don't think it's exploitable. IHMO, the main point is to give a useful debug to the user rather than an obscure error message because the given pointer is invalid (perhaps by mistake). > I'm considering whether to add an #ifndef NDEBUG check here which will > reject a multicall from a 32-bit guest where any of the arguments > (arm_hypercall_table[nr].nr_args) are non-zero in their top 32-bit. I > can't decide whether -EINVAL or domain_kill() would be more appropriate. > I'm actually leaning towards the latter. > > Thoughts? Killing the domain is a bit tough. But it seems that all failures in trap.c result to crash the domain. Regards, -- Julien Grall