[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen: arm: fully implement multicall interface.
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |