[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 7/7] tools, libxl: handle the iomem parameter with the memory_mapping hcall
On Tue, 2014-03-25 at 03:02 +0100, Arianna Avanzini wrote: > Currently, the configuration-parsing code concerning the handling of the > iomem parameter only invokes the XEN_DOMCTL_iomem_permission hypercall. > This commit lets the XEN_DOMCTL_memory_mapping hypercall be invoked > after XEN_DOMCTL_iomem_permission when the iomem parameter is parsed > from a domU configuration file, so that the address range can be mapped > to the address space of the domU. The hypercall is invoked only in case > of domains using an auto-translated physmap. Sorry for not noticing this sooner but I've just been looking at this again and it seems that XEN_DOMCTL_memory_mapping is a superset of XEN_DOMCTL_iomem_permission. AFAICT XEN_DOMCTL_memory_mapping does exactly the same iomem_{permit,deny}_access as XEN_DOMCTL_iomem_permission and then iff the guest is paging_mode_translate sets up a p2m mapping for it. (There's also some extra debug logging, lets ignore it). IOW could the toolstack's existing call to XEN_DOMCTL_iomem_permission not be completely replaced with a call to XEN_DOMCTL_memory_mapping and have exactly the same affect as this patch, without the need for the toolstack to infer the paging mode of the guest? I think the answer is yes, can someone confirm? One subtle distinction is that it appears that XEN_DOMCTL_memory_mapping cannot grant access to mfns for which it does not it self have access. That seems reasonable though. In fact the fact that XEN_DOMCTL_iomem_permission does not make this check could be a security issue -- a domain with permission to build domains could construct a sock puppet domain which it could give access to ports which it cannot see. Or maybe this is deliberate and isolates the builder domain from needing h/w permissions, in which case is XEN_DOMTL_memory_mapping wrong? Daniel? Ian. [0] which I am mentioning openly since it is listed in docs/misc/xsm-flask.txt as being an interface where we will handle issue publicly. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |