>>> On 15.08.16 at 14:07, <ian.jack...@eu.citrix.com> wrote: > Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu > depriv)"): >> On 15.08.16 at 12:47, <george.dun...@citrix.com> 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@lists.xen.org https://lists.xen.org/xen-devel