From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH] xen: arm: fully implement multicall interface. Date: Tue, 01 Apr 2014 10:05:23 +0100 Message-ID: <533A8153.3050708@linaro.org> References: <1396015649-5886-1-git-send-email-ian.campbell@citrix.com> <1396017905.8670.71.camel@kazak.uk.xensource.com> <53358EBE.4060303@linaro.org> <1396019237.8670.78.camel@kazak.uk.xensource.com> <53399A03.9020105@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53399A03.9020105@eu.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: George Dunlap , Ian Campbell Cc: keir@xen.org, stefano.stabellini@eu.citrix.com, tim@xen.org, jbeulich@suse.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 31/03/14 17:38, George Dunlap wrote: > On 03/28/2014 03:07 PM, Ian Campbell wrote: >> On Fri, 2014-03-28 at 15:01 +0000, Julien Grall wrote: >>> 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). >> Right. >> >> We also want to avoid the case where it just happens to work in one >> configuration (i.e. 32-on-32) but fails in another (i.e. 32-on-64). >> >>>> 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. >> Sure, but the point is to flush out 32-bit guests which make invalid >> assumptions which will be broken when they run on 64-bit vs. 32-bit Xen. > > Perhaps return -EINVAL for NDEBUG, and kill if !NDEBUG? > > We generally don't want to be killing production VMs unless absolutely > necessary. One would of course hope that we had caught any bugs during > development, but things don't always work the way you'd think... Out-of-context, I've noticed that most of trap failure will kill the domain. From the ARM ARM , if a coprocessor instruction is failing, we should generate an Undefined Instruction exception (see P.7.5). Regards, -- Julien Grall