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