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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 03.08.16 at 12:29, <ian.jackson@eu.citrix.com> wrote:
> 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.

Okay; nevertheless I did get the feeling that some of this was
prompted by the hvmctl series posting.

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

Indeed it does.

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

That series only moves code from one hypercall to another (new) one,
without any security implications at all. What has been available to
stubdoms prior to that series will be available the same way once it
got applied.

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

Well, none of that was the original goal of the series; some of this
could be merged in.

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

Correct. Yet again the original goal of the series was just proper
separation of two groups of operations that should never have
been all thrown under the same hypercall.

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

I agree that (i) would be the better approach, but I don't think I
can assess when I would find the time to do the required auditing
of all involved code. Plus I don't see the difference between going
the (ii) route with the presented hvmctl series vs keeping things as
they are (under hvmop) - in both cases the security promise will
need to be retrofit onto existing code.

Jan

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