Re: [Xen-devel] Xen hypercall API/ABI problems

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.06.13 at 17:43, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> In memory.c, there is a possible unsigned->signed conversion error from
> max_pages to rc.

That's of no concern as long as the maximum possible value can't
result in the value being negative. Plus it's problematic only when
the hypervisor is 32-bit (as otherwise it's a conversion from
"unsigned int" to "signed long".

And for the list of items to be complete - there's a similar conversion
for d->tot_pages.

> In compat/memory.c, there is a long->int truncation error for compat
> hypercalls, although newer versions of Xen cap this at INT_{MIN,MAX}

That was added precisely to avoid uncontrolled truncation.

> In the privcmd driver passes the hypercall rc through as the return from
> the ioctl handler, containing a possible long->int truncation error.

That's an outright bug, introduced by improper code transformations
when porting the XenoLinux code to the upstream kernel, or - if the
porting was done long enough ago - lack of noticing linux-2.6.18-xen.hg
c/s 984.

> From the work with XSA-55, we have already identified that the error
> handling and propagation in libxc leaves a lot to be desired.  However,
> the hypervisor side of things is just as problematic.

Given the above I'm not clear what problematic point you see.

> What policy do we have about deprecating hypercall interfaces and
> introducing newer ones?  At a minimum, all hypercalls should be using
> -errno style errors, with a possibility of returning 0 to LONG_MAX as well.
> 
> I realise that simply changing the hypercalls in place is not possible. 
> Would it be acceptable to have a step change across a Xen version (say
> early in 4.4) where consumers of the public interface would have to make
> use of -DXEN_LEGACY_UNSAFE_HYPERCALLS (or equivalent) in an attempt to
> move them forward with the API ?

That's what we have __XEN_INTERFACE_VERSION__ for - just
guard stuff you don't want up-to-date consumers to use anymore
with a respective #if __XEN_INTERFACE_VERSION__ < 0x040400.

Of course pv-ops is lacking any such version handling so far,
apparently with the original hope of only using up-to-date bits.

Jan


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