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

From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: StefanoStabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, GeorgeDunlap <george.dunlap@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	dgdegra@tycho.nsa.gov
Subject: Re: Device model operation hypercall (DMOP, re qemu depriv)
Date: Fri, 26 Aug 2016 06:58:16 -0600	[thread overview]
Message-ID: <57C059080200007800109659@prv-mh.provo.novell.com> (raw)
In-Reply-To: <22464.10816.978735.676484@mariner.uk.xensource.com>

>>> On 26.08.16 at 13:38, <ian.jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
>> On 08.08.16 at 15:46, <ian.jackson@eu.citrix.com> wrote:
>> > 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).
> 
> Right.
> 
> Let me try to think of some examples.  Thinking `aloud':
> 
> The real problem comes if a DMOP talks about the calling domain's
> resources or namespaces, implicitly or explicitly.
> 
> An example of an explicit reference to the calling domain's resources
> is the references to memory space in the calling domain (vaddrs).  We
> have already had an extensive discussion of that...
> 
> Another example would be a DMOP that takes (or returns) an event
> channel number in the calling domain.  This would be a problem because
> there would be nothing to stop qemu from messing about with evtchns
> which dom0 is using for other purposes (or conversely, there would be
> no way for the dom0 evtchn driver to know about the returned evtchn
> number and allow qemu to receive it).

Doesn't that follow the more general "mixing up own and target
domains" pattern, which is relatively easy to audit for?

> Another might be a DMOP that implicitly grants the target domain some
> of the calling domain's scheduling priority.  (I realise this is quite
> implausible from a scheduling API POV, but it gives an idea.)
> 
> Another example is that of course VCPU pool management and VCPU-PCPU
> pinning must not be available via DMOP.
> 
> (I write `qemu' here for brevity and clarity, but really I mean any
> DMOP caller which is supposed to be privileged for the target domain
> but not generally privileged.)

These all look rather contrived, especially keeping in mind that
what we mean to exclude right now are accidental violations of
the intended isolation. I.e. I think for all of those one would need
to go to some lengths to actually achieve the "goal", but they are
rather unlikely to be the result of a bug.

Jan

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