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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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).

Jan


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