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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

 -George




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