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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.08.16 at 16:57, <george.dunlap@xxxxxxxxxx> wrote:
> On 15/08/16 12:20, Jan Beulich wrote:
>>>>> On 15.08.16 at 12:47, <george.dunlap@xxxxxxxxxx> 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.

Well, you then discount the original vDSO range 64-bit Linux had
high up in the fixmap area. Not that this area would be usable for
any bad here, but it shows that such an idea isn't pure theory.

> 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.

That should work too, yes.

Jan


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