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

[Wei Liu <wei.liu2@citrix.com>]

On Tue, Aug 02, 2016 at 12:42:36PM +0100, George Dunlap wrote:
> On 02/08/16 12:37, Wei Liu wrote:
> > On Mon, Aug 01, 2016 at 12:32:54PM +0100, Ian Jackson wrote:
> >> Introducing HVMCTL, Jan wrote:
> >>> A long while back separating out all control kind operations (intended
> >>> for use by only the control domain or device model) from the currect
> >>> hvmop hypercall has been discussed. This series aims at finally making
> >>> this reality (at once allowing to streamline the associated XSM checking).
> >>
> >> I think we need to introduce a new hypercall (which I will call DMOP
> >> for now) which may augment or replace some of HVMCTL.  Let me explain:
> >>
> >>
> >> We would like to be able to deprivilege qemu-in-dom0.  This is
> >> because qemu has a large attack surface and has a history of security
> >> bugs.  If we get this right we can easily reduce the impact of `guest
> >> can take over qemu' bugs to DoS; and perhaps with a bit of effort we
> >> can eliminate the DoS too.  (qemu stubdom are another way to do this
> >> but they have their own difficulties.)
> >>
> >> A part of this plan has to be a way for qemu to make hypercalls
> >> related to the guest it is servicing.  But qemu needs to be _unable_
> >> to make _other_ hypercalls.
> >>
> >> I see four possible approaches.  In IMO increasing order of
> >> desirability:
> >>
> >> 1. We could simply patch the dom0 privcmd driver to know exactly which
> >>    hypercalls are permitted.  This is obviously never going to work
> >>    because there would have to be a massive table in the kernel, kept
> >>    in step with Xen.  We could have a kind of pattern matching engine
> >>    instead, and load the tables from userspace, but that's a daft
> >>    edifice to be building (even if we reuse BPF or something) and a
> >>    total pain to maintain.
> >>
> >> 2. We could have some kind of privileged proxy or helper process,
> >>    which makes the hypercalls on instruction from qemu.  This would be
> >>    quite complicated and involve a lot of back-and-forth parameter
> >>    passing.  Like option 1, this arrangement would end up embedding
> >>    detailed knowledge about which hypercalls are appropriate, and have
> >>    to understand all of their parameters.
> >>
> >> 3. We could have the dom0 privcmd driver wrap each of qemu's
> >>    hypercalls in a special "wrap up with different XSM tag" hypercall.
> >>    Then, we could specify the set of allowable hypercalls with XSM.
> >>    If we want qemu deprivileged by default, this depends on turning
> >>    XSM on by default.  But we want qemu depriv ASAP and there are
> >>    difficulties with XSM by default.  This approach also involves
> >>    writing a large and hard-to-verify hypercall permission table, in
> >>    the form of an XSM policy.
> >>
> >> 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.
> >>
> > 
> > I think your analysis makes sense.
> > 
> >>
> >> 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.
> >>
> > 
> > I would like to point out that this is non-trivial since we would need
> > to audit a lot of stuff.
> > 
> > But the requirement to audit interface is not unique to DMOP -- I expect
> > this is needed for any other approach.
> > 
> >> In the privcmd driver, we provide a new restriction ioctl, which takes
> >> a domid parameter.  After that restriction ioctl is called, the
> >> privcmd driver will permit only DMOP hypercalls, and only with the
> >> specified target domid.
> >>
> > 
> > It is phrased like that the guest kernel is supposed to enforce the
> > policy?  Would it be possible to make Xen do it? I don't think we should
> > trust DM domain kernel here.
> 
> The problem is that Xen doesn't know what process is running, and so
> can't tell whether qemuA is accessing domainA's memory, or whether qemuB
> is accessing domainA's memory.
> 
> The two options that have been proposed are:
> 
> 1. Have a way for dom0 to give Xen an XSM tag for the current process
> (so Xen can do the enforcing)
> 
> 2. Have dom0 filter out the calls based on the fact that all the
> hypercalls have the same template (i.e., domid in the same position).
> 
> Either way you are relying on dom0 ("trusting" dom0) to DTRT -- either
> to do the filtering properly, or to give you the right XSM tag.
> 

Right. I think that's what slipped my mind. Thanks for explaining!

Wei.

>  -George
> 
> 
> 

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