Re: New AMD IOMMU Spec (1.2)

Eric Smith <eric@xxxxxxxxxxxx> wrote:
+---------------
| Most people don't consider what the effect could be of someone
| discovering a remotely exploitable vulnerability in the firmware
| of a PCI (or Cardbus, ExpressCard, etc.) wireless card, but without
| something like the IOMMU it can compromise the security of the whole
| system.
+---------------

On the other hand, *with* something like the IOMMU it can
compromise the I/O *and* CPU performance of the whole system
if the IOMMU isn't designed "just exactly right" or if the
operating system *and* the DMA device aren't designed to
make good use of it. Otherwise, the operating system ends up
spending *way* too much time updating the IOMMU, way too often.

It's a tradeoff. If it gets too bothersome, performance-sensitive
driver writers will simply static-map all of physical memory
contiguously and hand their "smart" devices linear addresses
in that single map.

I haven't seen the spec for the AMD IOMMU yet, but I would not be
surprised if a serious performance "gotcha" were to show up in the
first version or two. Getting it "right" is hard.


-Rob

p.s. One of the reasons all of the "new" (circa 1996) SGI-designed
PCI devices for the SGI Origin system were "A64"-capable was
precisely to avoid having to touch the IOMMU *at all* during DMA
[since PCI DMA using 64-bit addressing went around it completely].
This allowed such devices as fast network to rip through large
scatter/gather descriptor rings at bus speed, and do such things
as managed large "pre-staged" pools of anonymous buffer pages
(given to the card by the O/S agead of time) that could handed out
to whichever user process the incoming packets were targeted for,
*without* having to know in advance which processes that would be.

Unfortunately, there were a handful of "A32" legacy devices and
even some (unfortunately critical, in some cases) 3rd-party "A32/D64"
devices [that's right, 64-bit-wide data, but only 32-bit addressing!]
for which the IOMMU *had* to be used. The constant updating was...
painful.

-----
Rob Warnock <rpw3@xxxxxxxx>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607


.

Relevant Pages

  • Re: Is Athlons IOMMU supported?
    ... The IOMMU is like the standard MMU an address translation mechanism. ... It translates e.g. PCI DMA addresses, though, instead of logical ... since the PCI controller ...
    (microsoft.public.development.device.drivers)
  • IOMMUs was Re: Intel vs AMD x86-64
    ... > IOMMU. ... right now their AGP bridges are all 32-bit limited ... PCI especially for Linux, ... What I find especially ironic is that exactly the same chipset ...
    (Linux-Kernel)
  • Re: [PATCH 0/2] x86: per-device dma_mapping_ops
    ... This change enables us ... to cleanly fix the Calgary IOMMU issue that some devices are not ... behind the IOMMU. ... It also would be helpful to handle KVM PCI ...
    (Linux-Kernel)
  • Re: [PATCH 0/2] x86: per-device dma_mapping_ops
    ... This change enables us ... to cleanly fix the Calgary IOMMU issue that some devices are not ... behind the IOMMU. ... It also would be helpful to handle KVM PCI ...
    (Linux-Kernel)
  • Re: [PATCH]intel-iommu batched iotlb flushes
    ... PTE's after an unmap operation. ... The following patch batches the IOTLB flushes removing most of the ... warnings from errant DMA operations is somewhat reduced, ... designed to conserve IOMMU mappings for machines where IOMMU mappings ...
    (Linux-Kernel)