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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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