Re: [PATCH] xen: arm: fully implement multicall interface.

[Julien Grall <julien.grall@linaro.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