Re: Device model operation hypercall (DMOP, re qemu depriv)

From: "Jan Beulich" <JBeulich@suse.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: StefanoStabellini <sstabellini@kernel.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	dgdegra@tycho.nsa.gov
Subject: Re: Device model operation hypercall (DMOP, re qemu depriv)
Date: Tue, 02 Aug 2016 05:58:08 -0600	[thread overview]
Message-ID: <57A0A6F00200007800101BCB@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160802113808.GG22419@citrix.com>

>>> On 02.08.16 at 13:38, <wei.liu2@citrix.com> wrote:
> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
>> >>> On 01.08.16 at 13:32, <ian.jackson@eu.citrix.com> 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@lists.xen.org
https://lists.xen.org/xen-devel