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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-03-28 at 14:07 +0000, Ian Campbell wrote:=
> Before doing so we need to make the usual adjustments for ARM and turn
> the unsigned longs into xen_ulong_t.

After a discussion with Julien I'm wondering if the actual
do_multicall_call dispatcher (reproduced below) should be explicitly
truncating the args values from 64-bits to 32-bits for 32-bit guests,
since that is the actual size of hypercall arguments for a 32-bit guest.
When running on a 64-bit Xen the guest can only actually see the 32-bit
rN registers so for a normal hypercall their is an implicit truncation
in the h/w exception model.

This interface exposes a full 64-bit sized set of arguments even to
32-bit guests. On 32-bit Xen this is truncated by the call() which takes
register_t's, but this might hide latent issues in guest kernels. On
64-bit Xen those 64-bit values would be passed to the hypercall.

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'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?

Ian.

void do_multicall_call(struct multicall_entry *multi)
{
    arm_hypercall_fn_t call = NULL;

    if ( multi->op >= ARRAY_SIZE(arm_hypercall_table) )
    {
        multi->result = -ENOSYS;
        return;
    }

    call = arm_hypercall_table[multi->op].fn;
    if ( call == NULL )
    {
        multi->result = -ENOSYS;
        return;
    }

    multi->result = call(multi->args[0], multi->args[1],
                        multi->args[2], multi->args[3],
                        multi->args[4]);
}


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel