[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.