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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.08.16 at 14:07, <ian.jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
>> On 15.08.16 at 12:47, <george.dunlap@xxxxxxxxxx> wrote:
>> > 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.
> 
> How hard would it be to allow the caller to specify several allowable
> ranges ?

Not very hard - just like with so many things an additional level
of indirection would do.

> Note that the hypercall argument construction code in libxc already
> has to handle all hypercall argument memory specially, so libxc could
> automatically build a list of the arguments' memory addresses.
> 
> What would be needed is some kind of restriction on (or variant of)
> copy_* which double-checked against the list provided in the
> non-op-specific part of the hypercall.

Yeah, as George already mentioned. I'd favor "variant of", to avoid
penalizing all other callers.

Jan


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