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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 12/08/16 12:50, Jan Beulich wrote:
>>>> On 12.08.16 at 11:44, <george.dunlap@xxxxxxxxxx> wrote:
>> On 09/08/16 12:30, Jan Beulich wrote:
>>>>>> On 09.08.16 at 12:48, <ian.jackson@xxxxxxxxxxxxx> wrote:
>>>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
>>>> depriv)"):
>>>>> Actually, having thought about this some more, and taking this
>>>>> together with the expectations to the privcmd driver previously
>>>>> outlined, I think this part is problematic: If all the driver is to know
>>>>> is the position (within the interface structure) of the target domain
>>>>> ID, then any guest handles embedded in the interface structure
>>>>> (XEN_HVMCTL_track_dirty_vram only for now) couldn't get
>>>>> validated, and hence user mode code would have a way to access
>>>>> or modify kernel memory.
>>>>
>>>> Could the hypervisor know the difference between user and kernel
>>>> memory, in principle ?
>>>
>>> Not without further new hypercalls, as the guest kernel would need
>>> to tell Xen what address ranges are kernel vs user (and that implies
>>> that any OS wishing to be able to act as Dom0 has a uniform
>>> separation of address spaces).
>>
>> Couldn't Xen tell from the guest pagetables whether the memory being
>> accessed was user-mode or kernel mode?
> 
> That would be possible, but would feel like adding heuristics instead
> of a proper distinction. Clearly we'd already be in some trouble if
> there were cases where some structure doesn't get written to (and
> hence could live in user-r/o mapped space), but others would need
> to be verified to be user-r/w mapped. A lot of special casing, that is,
> and hence of lot of things to be got wrong.
> 
> And then there is the problem of calling code being in rings 1 or 2:
> Page tables don't guard ring 0 against such, and we don't even have
> the notion of selectors (and hence address ranges) bounding
> accessible regions. We can't even say we assume all of them to be
> %ds-relative, as it would certainly be legitimate for such a structure
> to e.g. live on the stack. Of course an option would be to require
> the kernel driver to not allow requests from other than ring 3.
> 
> Plus finally - how would we tell interface structures coming from a
> kernel invoked hypercall from those originating from user mode?
> There would need to be at least some kind of flag then, which the
> privcmd driver set, but normal hypercalls originating in the kernel
> don't. Or would you envision to allow this DMOP hypercall to only
> be made by user mode tools? If so, does stubdom run its qemu in
> ring 3 or rather in ring 0?
> 
> [breaking the order of quoting]
>> And unless we're positive the guest kernel will never need these
>> hypercalls, we probably need a flag that allows kernel-mode pointers.
> 
> Ah, you actually mention that already.
> 
>>>>  (Would it be sufficient to check the starts, or would
>>>> the ends need to be checked too?)
>>>
>>> Both would need to be checked, so the size field(s) would need to
>>> be locatable too.
>>
>> We could have the "fixed" part of the structure contain domid and an
>> array of <ptr, len> which the privcmd driver could check.  I don't think
>> that would be terrible.
> 
> Doable, yes, but not really nice, especially for the party invoking
> the hypercall as well as the backing implementation in Xen (as
> opposed to the privcmd driver, for which such a model would likely
> work quite well), as they  then can't use the normal, simple reading
> of structure fields, but instead would need to populate array
> elements in the right order.

So on the whole, what would be your suggestion for how to solve the
userspace-pointer problem?

 -George


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