Re: [Xen-devel] [PATCH 3/5] xen: few more xen_ulong_t substitutions

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

> >> > do_memory_op has the following check:
> >> > 
> >> >     /* Is size too large for us to encode a continuation? */
> >> >     if ( reservation.nr_extents > (ULONG_MAX >> MEMOP_EXTENT_SHIFT) )
> >> >         return start_extent;
> >> > 
> >> > it would work as-is for ARM too.
> >> 
> >> Not afaict. For a 32-bit guest, but the above code executed in
> >> a 64-bit hypervisor, the guest could pass in (theoretically)
> >> UINT_MAX, which would pass this check, yet the eventual
> >> continuation index would get truncated when stored in the
> >> 32-bit hypercall operation field.
> >  
> > Actually, like Ian wrote, I expect that using the upper 32 bit part of
> > the x0 register, only for continuations, would work just fine.
> > 
> > In any case we can make that check arch dependent and restrict the
> > maximum number of extents on aarch64 to the same limit we have on
> > aarch32.
> 
> We should even discuss lowering the limit universally to the
> UINT_MAX based value. I don't think anyone is actively using
> such insane numbers.

I am OK with that, it would make things easier for me.


> And don't forget that I pointed out this issue only as example
> of possible problems with your intended approach to the
> handling of multicalls.

I just went through the hypercall continuations in common code, and
do_memory_op is the only one that uses this "trick" of encoding the
start extent in another parameter.
I think we'll have to deal with these issues as we find them out.

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