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

[Ian Jackson <ian.jackson@eu.citrix.com>]

Wei Liu writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"):
> On Mon, Aug 01, 2016 at 06:41:20AM -0600, Jan Beulich wrote:
> > > 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.

I don't (currently) have a clear understanding of how my proposed DMOP
relates to HVMCTL.

I thought it useful to set out the DMOP proposal from first
principles, with clear motivation, discussion of not-chosen
alternatives, and of course with a clear statement of the principles
of operation and of the security design.

The security property I have quoted above is absolutely critical to
the DMOP proposal.  I'm a bit concerned by comments like the above
`with the exception of this' (which seems to refer to the security
property).

Earlier during one of the HVMCTL threads I asked

    This is a slight digression, but is it intended that all of these
    hvmctl's are safe to expose to a deprivileged device model process in
    dom0, or to a device model stub domain ?

Jan replied:

    Yes, afaict (they've been exposed the same way before).

Does that mean that functionality exposed by all the prooposed HVMCTLs
is currently available to stubdoms ?

> Yeah, to turn HVMCTL to DMOP:
> 
> 1. s/HVMCTL/DMOP/
> 2. maybe s/interface_version//

Well, that would certainly be nice.  But there are some caveats I
would like sorting out.

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

Please don't misunderstand me as trying to compete with or block
your HVMCTL work.  It may well be that HVMCTL is what I want, but:

If we adopt the design principles I describe in my DMOP proposal, I
don't think the security concerns are separable.

ISTM that a patch series introducing DMOP should start with a patch
which introduces the DMOP hypercall, with no sub-operations.

Such a patch would have code content very like that in
  [PATCH 01/11] public / x86: introduce hvmctl hypercall

But, such a patch should also explain the semantics.  The Xen public
headers ought to contain explanations of the promises that the
hypervisor makes about DMOP.  Importantly:
 - the promise that a DMOP cannot harm anyone except the target domid
 - the ABI stability of the target domid field
 - what the ABI stability policy is wrt the actual DMOPs themselves

If the 01/ patch contains such promises, then logically the 02/ patch
which introduces the first DMOP is extending that promise to that
operation.  It is at that point that the security decision should be
made.

Now, there may be other ways to represent/record the security status.
But it will be necessary to either (i) avoid violating the DMOP
security promise, by making questionable calls not available via DMOP
or (ii) trying to retrofit the security promise to DMOP later.

I think (ii) is not a good approach.  It would amount to introducing a
whole new set of interfaces, and then later trying to redefine them to
have a particular security property which was not originally there.

Ian.

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