Re: [Xen-devel] [PATCH] VT-d: fix RMRR handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 10/02/14 13:42, Jan Beulich wrote:
> Removing mapped RMRR tracking structures in dma_pte_clear_one() is
> wrong for two reasons: First, these regions may cover more than a
> single page. And second, multiple devices (and hence multiple devices
> assigned to any particular guest) may share a single RMRR (whether
> assigning such devices to distinct guests is a safe thing to do is
> another question).
>
> Therefore move the removal of the tracking structures into the
> counterpart function to the one doing the insertion -
> intel_iommu_remove_device(), and add a reference count to the tracking
> structure.
>
> Further, for the handling of the mappings of the respective memory
> regions to be correct, RMRRs must not overlap. Add a respective check
> to acpi_parse_one_rmrr().
>
> And finally, with all of this being VT-d specific, move the cleanup
> of the list as well as the structure type definition where it belongs -
> in VT-d specific rather than IOMMU generic code.
>
> Note that this doesn't address yet another issue associated with RMRR
> handling: The purpose of the RMRRs as well as the way the respective
> IOMMU page table mappings get inserted both suggest that these regions
> would need to be marked E820_RESERVED in all (HVM?) guests' memory
> maps, yet nothing like this is being done in hvmloader. (For PV guests
> this would also seem to be necessary, but may conflict with PV guests
> possibly assuming there to be just a single E820 entry representing all
> of its RAM.)
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Having read up on RMRRs again, I suspect it is more complicated.  RMRRs
are for legacy devices which need to DMA to the BIOS to function
correctly.  In the case of dom0, they should necessarily be identity
mapped in the IOMMU tables (which does appear to be the case currently).

For domains with passthrough of a device using an RMRR, then the region
should be marked as reserved (and possibly removed from the physmap for
HVM guests?), and the IOMMU mappings again identity mapped, so the
device can talk to the BIOS.  Having the device talk to an
equally-positioned RMRR in the guest address space seems pointless. 
Furthermore, XenServer has had one support escalation which touched upon
this.  It turned out to be unrelated to the problem causing the
escalation, but was identified as something which should be handled better.

One way or another, the security when passing through devices covered by
RMRR would end up being reduced.

~Andrew

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