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

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

Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu depriv)"):
> On 15.08.16 at 16:50, <david.vrabel@citrix.com> wrote:
> > It seems simpler to me to have in the privcmd driver:
> > 
> >     if (op == HVMCTL_track_dirty_vram)
> >         ret = access_ok(...);
> > 
> > It looks simpler to me to fix the ABI and add the checking in the
> > privcmd driver than add one of the proposed mechanisms to allow the
> > hypervisor to do the checking.
> 
> Simpler, yes, but ...
> 
> > To avoid the issues with having to update the kernel in lock-step with
> > the hypervisor (if new checks are needed in privcmd), we can (in the
> > common case) do version the checking in the driver.
> > 
> > i.e., if the privcmd drivers knows about hypervisor ABI V but qemu needs
> > V+1 then it can choose to disable the depriv and thus continue to work
> > (with reduced defense in depth).
> 
> ... less flexible, and prone to end up in a mess once we have more
> than a handful of versions for the driver to deal with.

I agree.

To summarise the current proposal:

DMOP is roughly the same as Jan's HVMCTL.  It needs two
enhancements compared to HVMCTL:

 * Each hypercall transferred to DMOP[1] must promise not to do bad
   things to the calling domain (or to the whole system).  There will
   need to be some minimal audit (or consideration of the hypercall's
   functionality) for this purpose.  Jan thinks this is not too much
   work but wants an example or two of a plausible vulnerability that
   needs to be excluded.

 * We will need to enable the privcmd driver to defend dom0's memory.

   This will be done by: the privcmd driver specifying to the
   hypervisor (either inside each DMOP hypercall struct, or in a
   previous hypercall) a single address range which is permitted for
   this purpose.  (This would be the vaddr range which is used for
   userspace.)

   If the range is specified separately, the DMOP hypercall needs a
   flag to say whether this specific DMOP call ought to be subject to
   the restriction.


We also discussed compatibility.  We need to present a stable ABI and
API to qemu.  We considered making a limited stability promise for the
DMOP hypercalls, but this would involve the hypervisor supporting
multiple old versions of DMOPs which is not ideal from a security
point of view.  Instead, it is proposed that this will be dealt with
in libxc.

In more detail, I think the plan has then to look something like this:

Suppose a DMOP is introduced in Xen version K, and then modified in a
non-ABI-compatible way Xen version K+1.

Xen K+1 implements only the new ABI, and Xen K provides only the old.
libxc in K provides only the single entrypoint for the old DMOP.

libxc in K+1 provides a new entrypoint for the new DMOP (with enhanced
parameters, or whatever).  This new entrypoint needs no compatibility
handling and works only only Xen >= K+1 (and otherwise returns
ENOSYS).

However, libxc K+1 it also provides the old entrypoint.  This old
entrypoint checks the hypervisor DMOP ABI version, and makes either
the old or new hypercall.

For this to work, the ABI definition for the retired DMOP must remain
in xen.git somewhere, so that the code in libxc can call it.

Also, there should be a single DMOP ABI version which can be retrieved
by the hypervisor and cached by libxc.  This could be the hypervisor
ABI version if we don't mind breakage during development.


Is this plan a good one for everyone ?

Thanks,
Ian.


[1] By this I don't mean to take a point of view about the name.

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