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

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

>>> On 08.08.16 at 15:46, <ian.jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
>> I'm having, however, a hard time imagining a class 2 bug for any
>> of the hvmop-s that are being converted by the hvmctl series:
>> These act on the target domain, so would not touch the calling
>> ones state other than for copying argument structures to/from
>> guest memory (and I don't view mixing up domain pointers as
>> a likely source of problems).
> 
> Right.  AIUI all the hypercall arguments are passed using
> calling-guest-virtual addresses, which the dom0 privcmd arrangements
> are capable of ensuring are sane.
> 
>> Any other problem they might
>> reasonably have would then affect the system as a whole (class
>> 1) or just the target domain (non-security bug).
> 
> So would it therefore be OK to introduce the enhanced security promise
> - the lack of `class 2' bugs - for HVMCTL from the beginning ?

I think so, since ...

> This would involve a small amount of extra thought for each invididual
> hypercall, just to check that the assumptions we are relying on (as
> you put them above) are not violated.

... this looks to be a manageable amount of code auditing (albeit
I'd like to see whether someone else can perhaps come up with
some potential, more realistic kind of bug that could fall into class
2 before volunteering to make an attempt at doing such an audit).

> If so then good, but I think we still need to have a proper
> conversation about how we are going to provide ABI stability to qemu
> in practice.

Yes, the ABI stability aspect still needs coming to an agreement.
Since relaxation is easier than tightening, I'm going to retain the
current way the patches are in this regard, i.e. assume an
unstable hypercall ABI.

Jan


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