Re: [Xen-devel] [PATCH 19/22] arch/x86: check remote MMIO remap permissions

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.09.12 at 18:46, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> For this example, assume domain A has access to map domain B's memory
> read-only. Domain B has access to a device with MMIO where reads to the
> device's memory cause state changes - an example of such as device is a
> TPM, where replies are read by repeated reads to a single 4-byte 
> address. Domain A does not have access to this device, and would like to
> maliciously interfere with the device.
> 
> If domain A maps the MMIO page from domain B using pg_owner == domB, the
> iomem_access_permitted check will be done from domain B's perspective. 
> While this is needed when domain A is mapping pages on behalf of domB, 
> it is not sufficient when attempting to constrain domain A's access. 
> 
> These checks only apply to MMIO, so the condition on line 735 will
> evaluate to true (!mfn_valid || real_pg_owner == dom_io).
> 
> The (existing) check on domain B's MMIO access is:
>         if ( !iomem_access_permitted(pg_owner, mfn, mfn) )
> 
> This patch adds a check on domain A:
>         if ( !iomem_access_permitted(curr->domain, mfn, mfn) )

So then I think I was right suggesting that the second check
should be done at the same place where the first one is, not
outside/after the MMIO conditional.

> This extra checking has not been required without XSM because only FLASK
> implements the ability to grant one domain read-only access to another 
> domain. With read-write access, this extra access check is simple to get
> around: domain A can modify some part of the executable code in domain B
> to act as a proxy for its accesses. Additionally, domain A is usually
> dom0 or the device model, which have equal or greater MMIO access.

Understood.

Jan


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