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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 1 April 2014 16:13, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> 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?

For x86 HVM, AFAIU only QEMU knows the memory layout of the guest.
So we can't call XEN_DOMCTL_memory_mapping here (at least map
the range in the p2m).

> 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?

I think XEN_DOMCTL_memory_mapping is correct (and therefore
XEN_DOMCTL_iomem_permission) wrong. It make senses which the
builder domain patch series from Daniel:
see http://lists.xen.org/archives/html/xen-devel/2014-03/msg03553.html

> [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.

There is no reference of [0] in the mail. I guess you were talking
about the last
paragraph? :)

-- 
Julien Grall

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