Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.08.16 at 15:02, <david.vrabel@xxxxxxxxxx> wrote:
> On 02/08/16 12:58, Jan Beulich wrote:
>>>>> On 02.08.16 at 13:38, <wei.liu2@xxxxxxxxxx> wrote:
>>> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
>>>>>>> On 01.08.16 at 13:32, <ian.jackson@xxxxxxxxxxxxx> wrote:
>>>>> 4. We could invent a new hypercall `DMOP' for hypercalls which device
>>>>>    models should be able to use, which always has the target domain in
>>>>>    a fixed location in the arguments.  We have the dom0 privcmd driver
>>>>>    know about this one hypercall number and the location of the target
>>>>>    domid.
>>>>>
>>>>> Option 4 has the following advantages:
>>>>>
>>>>> * The specification of which hypercalls are authorised to qemu is
>>>>>   integrated with the specification of the hypercalls themselves:
>>>>>   There is no need to maintain a separate table which can get out of
>>>>>   step (or contain security bugs).
>>>>>
>>>>> * The changes required to the rest of the system are fairly small.
>>>>>   In particular:
>>>>>
>>>>> * We need only one small, non-varying, patch to the dom0 kernel.
>>>>>
>>>>>
>>>>> Let me flesh out option 4 in more detail:
>>>>>
>>>>>
>>>>> We define a new hypercall DMOP.
>>>>>
>>>>> Its first argument is always a target domid.  The DMOP hypercall
>>>>> number and position of the target domid in the arguments are fixed.
>>>>>
>>>>> A DMOP is defined to never put at risk the stability or security of
>>>>> the whole system, nor of the domain which calls DMOP.  However, a DMOP
>>>>> may have arbitrary effects on the target domid.
>>>>
>>>> With the exception of this and the privcmd layer described below,
>>>> DMOP == HVMCTL afaics. The privcmd layer is independent anyway.
>>>> And the security aspect mentioned above won't disappear if we
>>>> use DMOP instead of HVMCTL. So I don't see why the hvmctl
>>>> series as is can't be the starting point of this, with the stability/
>>>> security concerns addressed subsequently, for being orthogonal.
>>>>
>>>
>>> Yeah, to turn HVMCTL to DMOP:
>>>
>>> 1. s/HVMCTL/DMOP/
>>> 2. maybe s/interface_version//
>> 
>> Andrew had brought up 2 too, but I'm really not sure that'd be a
>> good idea. I rather think we should keep it but maybe (other than
>> domctl/sysctl) recognize older versions. In any event I consider
>> having it better for an unstable interface (as Ian said, libxc is
>> supposed to provide the stable one).
> 
> A stable user space library API is no good for an in-kernel emulator,
> like that needed for Intel GVT-g -- the hypercall ABI needs to be stable.

I'm pretty certain only a (perhaps small) subset of the proposed new
operations would be needed by them, which we could then consider
marking stable.

Jan


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