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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
depriv)"):
> On 03.08.16 at 18:10, <ian.jackson@xxxxxxxxxxxxx> wrote:
> > George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu 
> > depriv)"):
> >> So before qemu devpriv can be usable, *all* the HVMCTL operations would
> >> need to be audited, and those that were deemed insecure would need to be
> >> either fixed or removed.
> > 
> > Even worse, the bad HVMCTLs would be retrospectively turned into
> > security-bugs-in-old-hypervisors.  I don't think this is tenable.
> 
> How would a bug in the respective current hvmop then not be a
> security issue as well?

AFAICT there are two kinds of possible bug:

1. An HVMCTL (or hvmop) that can have an adverse affect on the whole
system.  Such bugs would already be security bugs, covered by our
security support policy.  Such a bug would be a security bug whether
the operation is an hvmop or an HVMCTL or a DMOP.

2. An HVMCTL (or hvmop) that can have an adverse effect on the calling
domain.  Such bugs are not currently security bugs.  But the of qemu
depriv project requires them to be removed.  Such such a bug is a
security bug if it is a DMOP[1] but not otherwise.

By "is a security bug if it is a DMOP" I mean "is a security bug if
exposed via a hypercall which promises the security property necessary
for DMOP, even if that hypercall is called something else".

Strictly speaking, in order to move existing hypercalls into a new
DMOP hypercall, no further auditing is required for bugs of class 1
(other than that the privilege check is correct, ie that the new DMOP
is indeed currently available to stub device models).

But in order to move hypercalls into a new DMOP hypercall, they need
to be checked for bugs of class 2.

If we move some hypercalls which have potential bugs of class 2 from
hvmop to HVMCTL, and then later think we want to create something like
DMOP, we have a number of choices:

We can invent a new DMOP hypercall and start moving everything from
HVMCTL to DMOP as we audit it.

We could audit every HVMCTL, recording the audit status in-tree
somewhere, moving hypercalls with class 2 problems out of HVMCTL to a
new hypercall, and eventually, after we have audited everything, we
could change HVMCTL's hypercall number (and maybe rename it DMOP).

What we cannot do is audit every HVMCTL, fix the class 2 problems, and
then declare HVMCTL to have the relevant security property, and
implement corresponding code in dom0's privcmd drivers which relies on
the security property.  This is because the dom0 privcmd driver
doesn't know whether the HVMCTLs it is allowing not-fully-trusted
userspace to make are actually trustworthy (with the specific
hypervisor version in question.)

Ian.

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