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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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//

I think we could at least do #1 and merge the series.

Wei.

> Jan
> 

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