Re: [Xen-devel] [PATCH v4 7/7] tools, libxl: handle the iomem parameter with the memory_mapping hcall

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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