El IOMMU: la MMU de los dispositivos que protege la RAM

La CPU tiene una MMU que traduce direcciones y aísla procesos: ningún proceso puede tocar la memoria de otro. Pero los dispositivos que hacen DMA se saltaban esa MMU y podían escribir cualquier dirección física del sistema. El IOMMU cierra ese agujero: es la MMU de los dispositivos. Traduce sus direcciones y, sobre todo, los confina, de modo que un periférico defectuoso o comprometido ya no puede leer toda tu RAM.

Una MMU para los dispositivos

El IOMMU (I/O Memory Management Unit) se interpone entre el DMA del dispositivo y la RAM. El dispositivo emite una dirección virtual de E/S —una IOVA—, y el IOMMU la traduce a física recorriendo tablas de página de E/S propias, distintas de las de la CPU y organizadas por dispositivo. En hardware son Intel VT-d, AMD-Vi y el SMMU de ARM; en el kernel los orquesta el subsistema iommu y el backend iommu-dma, que es quien atiende tus llamadas a la DMA API cuando hay traducción activa.

# ¿hay IOMMU activo? sus grupos aparecen en sysfs
ls /sys/kernel/iommu_groups/
# habilitarlo desde la linea de comandos del kernel:
#   intel_iommu=on      (Intel VT-d)
#   amd_iommu=on        (AMD-Vi)

Esta traducción, por sí sola, ya resuelve dos problemas del nivel anterior. Un dispositivo de 32 bits puede alcanzar cualquier página física porque el IOMMU le da una IOVA baja que traduce a una física alta, sin buffer de rebote. Y páginas físicamente dispersas pueden presentarse al dispositivo como un rango de IOVA contiguo (la fusión del nivel 27.5).

Protección: confinar, no confiar

El verdadero salto no es la traducción sino la protección. Cuando dma_map_single instala una entrada en las tablas del IOMMU, está diciendo: “este dispositivo puede tocar esta página y ninguna otra”. Cualquier acceso del dispositivo a una IOVA no mapeada se rechaza y genera un fallo. El dispositivo pasa de tener acceso total a la RAM a vivir en una jaula que solo contiene lo que explícitamente le prestaste.

# desmapear estricto: cada unmap purga la IOTLB al instante (mas seguro, mas lento)
#   iommu.strict=1
# modo diferido: se agrupan las purgas (mas rapido, ventana breve de mapeo obsoleto)
#   iommu.strict=0
# passthrough: mapa identidad, sin proteccion, maximo rendimiento
#   iommu.passthrough=1   (equivale a iommu=pt)

flowchart LR
DEV[Dispositivo] -->|IOVA| IOMMU[IOMMU]
IOMMU -->|traduce y comprueba| OK[Paginas mapeadas para el]
IOMMU -. rechaza el acceso .- NO[Resto de la RAM]

Esto es exactamente lo que frena los ataques por DMA. Un portátil sin IOMMU es vulnerable a un periférico malicioso conectado por Thunderbolt o PCIe que, como maestro del bus, lee la RAM entera y roba claves de disco o de sesión: son los ataques Thunderclap, la clase evil maid y herramientas como PCILeech. Con el IOMMU activo y en modo estricto, ese periférico solo ve las poquísimas páginas que su driver le mapeó, y su intento de barrer la memoria muere en un fallo de traducción.

Grupos IOMMU: la unidad de aislamiento

El IOMMU no siempre puede distinguir dos dispositivos. Por la topología PCIe —puentes sin ACS, funciones que comparten origen— a veces varios dispositivos son indistinguibles desde el punto de vista de la traducción. El kernel los agrupa en un grupo IOMMU: el conjunto más pequeño que puede aislarse del resto. Todo el grupo comparte destino, y por eso es la granularidad mínima con la que puedes ceder un dispositivo a otro dominio.

# ver qué dispositivos comparten grupo (todos se ceden juntos, o ninguno)
for d in /sys/kernel/iommu_groups/*/devices/*; do
	echo "grupo $(basename $(dirname $(dirname $d))): $(basename $d)"
done

Virtualización segura: VFIO e IOMMUFD

Aquí el IOMMU cambia de “medida de seguridad interna” a “habilitador de arquitecturas enteras”. VFIO (Virtual Function I/O) permite ceder un dispositivo físico directamente a una máquina virtual o a un proceso de usuario con seguridad, precisamente porque el IOMMU confina el DMA de ese dispositivo a la memoria del huésped: el dispositivo cedido no puede escribir fuera de la RAM asignada a la VM. Es la base del passthrough de PCI en KVM y de los drivers en espacio de usuario de alto rendimiento como DPDK y SPDK.

# ceder un dispositivo PCI a vfio-pci para pasarlo a una VM bajo control del IOMMU
echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
echo vfio-pci     > /sys/bus/pci/devices/0000:03:00.0/driver_override
echo 0000:03:00.0 > /sys/bus/pci/drivers_probe

En los kernels actuales, IOMMUFD (/dev/iommu) moderniza ese modelo: expone la gestión de espacios de direcciones de E/S como un objeto de primera clase, con control fino de las tablas y soporte para anidamiento (el IOMMU de un huésped sobre el del anfitrión). VFIO se apoya cada vez más en él. La idea de fondo no cambia: el IOMMU es lo que hace seguro dar hardware crudo a software no confiable.