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

From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: StefanoStabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	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: Mon, 15 Aug 2016 15:57:43 +0100	[thread overview]
Message-ID: <fb9e9450-7aea-c621-01cd-9e26b3f5a022@citrix.com> (raw)
In-Reply-To: <57B1C1A70200007800105EEB@prv-mh.provo.novell.com>

On 15/08/16 12:20, Jan Beulich wrote:
>>>> On 15.08.16 at 12:47, <george.dunlap@citrix.com> wrote:
>> On 15/08/16 11:19, Jan Beulich wrote:
>>> Well, none of the options considered so far are really nice or
>>> readily available. I think the easiest to use for both the caller and
>>> the implementation of the hypercall would be the auxiliary
>>> hypercall for a kernel to indicate user/kernel boundaries plus a
>>> flag on the DMOP one for the kernel mode driver to indicate its
>>> user mode origin. The main (purely theoretical afaict) downside
>>> of this is the difficulty to use it in OSes with variable user/kernel
>>> boundaries.
>>
>> What about including in the "fixed" part of the hypercall a virtual
>> address range that all pointers must be in?  That wouldn't even require
>> a user/kernel flag actually; and could conceivably be used by the caller
>> (either userspace or kernel space) to thwart certain kinds of potential
>> attacks.
> 
> That's definitely an option, if we're sufficiently certain that no OSes
> will ever require two or more ranges.

I'm sorry, I think this is getting a bit silly.  There are currently no
known operating systems which have discontinuous user-space virtual
address ranges.  Even if there were, the hypercall structure I'm
proposing would still function; the only restriction would be that any
single hypercall would have to have all arguments within one of those
ranges.

If we find such a monster in the future, we can try to figure out how to
accommodate it at that point.

Another idea I had was to do a multi-call-style hypercall "wrapper"
hypercall, similar to David's XSM idea, but instead of running with a
specific XSM label, would restrict the target domain and VA range of all
included hypercalls.  Then the individual hypercall structure wouldn't
need to be known at all; and if it ever became important to have (say)
two VA ranges, we could simply add a new "wrapper" hypercall.

 -George

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