Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.11.15 at 18:06, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro 
> set_xen_guest_handle_raw"):
>> On 04.11.15 at 17:50, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > If we don't provide a get_xen_guest_handle, a kernel developer will be
>> > sorely tempted to make one.
>> 
>> What use would it be to them? Kernels only write handles, they
>> shouldn't have a need for reading them.
> 
> I foresee situations where a kernel might like to update a proposed
> hypercall argument structure in place, which might involve reading the
> handles.

I guess you think of e.g. the privcmd filtering done in XenServer, but
I think this is an odd thing for a kernel to do: Down to the final actual
hypercall invocation, it should deal with pointers, not handles.
Filtering should either be done prior to reaching that layer (obviously
not an option for privcmd, but that layer is guarded against issues
with the compiler doing the wrong thing afaict), or would better be
left to the hypervisor (said filtering in XenServer could likely be moved
into the hypervisor, with a flag added to the hypercall number
indicating whether to invoke the filtering, which the privcmd layer
then would set unconditionally).

Jan


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