Ataques DMA 101: Cómo la IOMMU impide que un dispositivo PCIe controle tu RAM

Tu CPU puede tener todas las protecciones modernas activadas: endurecimiento del kernel, SELinux/AppArmor, discos cifrados, arranque medido—y un solo
dispositivo PCIe aún puede leer y escribir tu RAM sin pedir permiso. Esto no es hipotético. Esto es DMA.

Si administras flotas, montas estaciones de trabajo seguras o haces passthrough de PCIe en entornos virtualizados, la IOMMU es uno de esos
controles de “o está activada y configurada correctamente, o te estás engañando a ti mismo”. Hagámoslo concreto: qué son los ataques DMA, qué
impone realmente la IOMMU y cómo probar que tu sistema hace lo que crees que hace.

DMA en términos sencillos: por qué los dispositivos pueden tocar tu memoria

DMA es “Acceso Directo a Memoria” (Direct Memory Access). El nombre es honesto: un dispositivo transfiere datos hacia o desde la memoria del sistema sin que la CPU
los copie byte a byte. La CPU configura la transferencia (buffers, direcciones, tamaños), luego el dispositivo se convierte en maestro del bus
y mueve la carga. Así es como el almacenamiento, las GPUs, las NICs y los controladores de alta velocidad alcanzan los números que promete la mercadotecnia.

El problema de seguridad también es honesto: si un dispositivo puede escribir en memoria física arbitraria, puede sobrescribir código del kernel,
modificar tablas de páginas, robar claves y leer cualquier cosa que pensabas que estaba “protegida” por el modelo de privilegios de la CPU. Los niveles
de privilegio de la CPU no aplican a un dispositivo PCIe. Al bus no le importan tus sentimientos.

Un driver bien diseñado programa el dispositivo para que haga DMA solo hacia buffers que el SO haya asignado. Pero “bien diseñado” es una elección de política,
y a los atacantes les encanta la política. Un periférico malicioso, un firmware de dispositivo comprometido o un error de driver pueden convertir el DMA en
“acceso a memoria sin supervisión”.

No puedes parchear esto con mejores ACLs. Necesitas una aplicación de hardware entre dispositivos y memoria. Esa aplicación es la IOMMU.

Por qué existe DMA (y por qué no puedes prohibirlo)

Si la CPU tuviera que copiar manualmente cada paquete de una NIC a la RAM y cada bloque de disco al page cache, o bien:
(a) tendrías un rendimiento ridículo, o (b) quemarías núcleos en movimiento de datos en lugar de hacer trabajo. Los sistemas modernos usan DMA más
moderación de interrupciones, pares de colas y scatter-gather para mantener a la CPU fuera del camino.

En almacenamiento y redes específicamente, DMA es cómo se obtiene línea completa y baja latencia. NVMe usa colas de envío/completado en memoria; el dispositivo hace DMA de los completados a RAM. Las NICs de alto rendimiento hacen DMA de buffers de paquetes a hugepages.
RDMA lo deja explícito: “por favor, deja que la NIC lea/escriba memoria de la aplicación”. Todo esto es genial—hasta que recuerdas que el
dispositivo está fuera del límite de privilegios de la CPU.

Dos modelos de amenaza que la gente confunde

Atacante físico con un dispositivo: alguien conecta un dispositivo en Thunderbolt/PCIe, o cambia una tarjeta interna,
o abusa de un puerto expuesto en un kiosco o una sala de servidores desatendida. No necesitan tu contraseña si pueden leer RAM.

Atacante de software que controla el DMA de un dispositivo: un driver comprometido, una explotación de kernel en la pila del dispositivo,
una VM maliciosa con passthrough PCI, o malware en el firmware dentro de un dispositivo PCIe. El atacante no necesita acceso físico; necesita
un camino para programar los motores DMA.

La IOMMU ayuda con ambos, pero las mitigaciones y hábitos operativos difieren.

Cómo ocurren los ataques DMA en la vida real

Los ataques DMA no son magia. Son una cadena: consigue un dispositivo que pueda emitir DMA, ponlo en el bus, luego apúntalo a la memoria.
La parte interesante es lo fácil que puede ser poner ese dispositivo en su lugar, y hasta dónde puedes llegar una vez que puedes leer la RAM.

Ruta de ataque 1: puertos externos de alta velocidad

Thunderbolt es efectivamente PCIe externo. Esa es la característica. También es el riesgo: conecta un dispositivo y potencialmente
añades un maestro de bus con DMA. Los sistemas modernos añaden capas como niveles de seguridad de Thunderbolt y autorización del SO, pero esas
no son lo mismo que “este dispositivo solo puede hacer DMA dentro de una caja de arena”.

Si la IOMMU está apagada o mal configurada, un dispositivo malicioso puede escanear la memoria física en busca de material de credenciales, estructuras del kernel o tablas de páginas. Si tienes suerte, “solo” filtras secretos. Si tienes mala suerte, el dispositivo escribe y convierte esa filtración en persistencia.

Ruta de ataque 2: firmware de dispositivo comprometido

Tu NIC tiene firmware. Tu SSD tiene firmware. Tu GPU tiene firmware. Tu controlador USB “simple” tiene firmware.
El firmware puede actualizarse, a veces automáticamente, a veces mediante utilidades del proveedor, a veces mediante el driver.

Si un atacante logra ejecutar firmware dentro de un dispositivo PCIe, ese dispositivo se convierte en un motor DMA no supervisado. El SO no puede
introspectarlo como hace con un proceso. Por eso la IOMMU se trata como línea base en sistemas de alta fiabilidad: mueve el límite de confianza más cerca de la RAM.

Ruta de ataque 3: virtualización y passthrough

El passthrough PCI (VFIO) da a una VM acceso directo a un dispositivo físico. El objetivo es rendimiento y acceso a funciones.
Sin la IOMMU, el passthrough no es “peligroso”. Es “le has dado a la VM una carretilla elevadora y la has apuntado a la memoria
del host.”

Con la IOMMU configurada correctamente, el dispositivo se restringe a la memoria asignada al invitado. Ese es todo
el modelo de seguridad detrás del passthrough seguro.

Ruta de ataque 4: errores de driver y “DMA al lugar equivocado”

No todos los incidentes de DMA son un atacante con capucha. Muchos son: “el driver programó una dirección DMA incorrectamente”,
o “el dispositivo escribió más allá del final de un ring buffer”, o “un error en un mapeo IOVA causó corrupción de memoria.”

La IOMMU puede convertir esos errores de “corrupción silenciosa” en “falla de IOMMU y un radio de daño contenido.” Eso es una victoria incluso
cuando no crees que estás bajo ataque.

Qué hace realmente una IOMMU (y qué no)

Una IOMMU es una Unidad de Gestión de Memoria para E/S. La CPU tiene una MMU que mapea direcciones virtuales a memoria física con permisos.
La IOMMU mapea direcciones visibles para el dispositivo a memoria física, también con permisos. Los dispositivos no necesariamente hablan “direcciones virtuales”,
así que la IOMMU les da un espacio de direcciones (IOVA) y hace cumplir qué pueden tocar.

El mecanismo central: traducción y comprobaciones de permisos para DMA

Cuando un dispositivo intenta hacer DMA a una dirección, esa dirección se interpreta en un dominio que controla el SO. La IOMMU traduce
ese IOVA a una dirección física y comprueba permisos. Si el mapeo no existe, o los permisos no permiten la operación, la IOMMU lo bloquea y normalmente informa una falla.

En la práctica, esto significa:

• Los dispositivos no pueden hacer DMA en RAM arbitraria solo porque sean maestros del bus.
• Cada dispositivo (o grupo de dispositivos) puede colocarse en un dominio de aislamiento.
• La virtualización puede asignar un dispositivo a un invitado y restringir el DMA a la memoria del invitado.
• Los drivers defectuosos provocan fallas ruidosas en lugar de corrupción silenciosa—si está configurada la aplicación estricta.

IOMMU ≠ escudo mágico

La IOMMU no te salva si nunca la activas, o si la activas pero dejas dispositivos en un dominio mapeado por identidad
donde IOVA==físico por “compatibilidad”. Tampoco protege contra un dispositivo que tiene permiso para DMA en un búfer y luego tú guardas secretos en ese búfer. El principio de menor privilegio sigue siendo importante.

Tampoco puede detener que un dispositivo malicioso haga daño dentro de su región permitida. Si das a una GPU acceso a la mitad de tu
RAM por “rendimiento”, tomaste una decisión. La IOMMU aplicará fielmente esa elección.

Intel VT-d, AMD-Vi y cómo Linux los nombra

En Intel, la IOMMU suele ser VT-d. En AMD, AMD-Vi (también llamada IOMMU, a veces “IVRS” en contextos ACPI).
En los logs de Linux verás “DMAR” en plataformas Intel, y “AMD-Vi” o “IOMMU” en AMD.

Linux usa APIs y drivers de IOMMU. Los dispositivos se asignan a grupos IOMMU, que importan mucho para la virtualización:
un grupo es la granularidad mínima de aislamiento que el kernel puede aplicar de manera segura basada en cómo están conectados los dispositivos y cómo
ACS (Access Control Services) está implementado en la topología PCIe. Si dos funciones pueden espiar el tráfico de la otra, terminan en un grupo,
y no puedes hacer passthrough de una sin la otra de manera segura.

Rendimiento: el coste es real, pero a menudo menor de lo que temes

La traducción de IOMMU añade sobrecarga: hay una caché de traducción (IOTLB), recorridos de tablas de páginas y comprobaciones extra.
Los dispositivos de alto rendimiento pueden estresarla. Pero las IOMMUs modernas son rápidas, y Linux tiene mitigaciones como batching, hugepages
y modos de passthrough por dispositivo cuando es apropiado.

La postura operativa que recomiendo: trata la aplicación completa de la IOMMU como predeterminada. Opta por excluir por dispositivo solo después de medir,
y solo cuando el modelo de amenaza lo permita. “Lo apagamos porque alguien dijo que es más lento” no es una decisión de ingeniería. Es un rumor con privilegios de root.

Una cita para mantener la honestidad

idea parafraseada — Werner Vogels: lo construyes para que falle de forma segura; no asumes que no fallará.

Datos históricos e información interesante

Aquí hay datos concretos de historia que explican por qué este tema vuelve a surgir cada pocos años como una mala actualización de dependencias.

1. El DMA es anterior a los modelos de seguridad modernos de los SO. Los sistemas tempranos usaban DMA para descargar CPUs lentas; la seguridad no fue el principal motor del diseño.
2. PCI hizo común el bus mastering. PCI y luego PCIe estandarizaron el acceso de dispositivos de alto rendimiento, haciendo del DMA una capacidad por defecto para muchos controladores.
3. FireWire fue un primer aviso sobre “DMA externo”. IEEE 1394 expuso acceso estilo DMA de maneras que sorprendieron a usuarios de portátiles y equipos de seguridad.
4. VT-d/AMD-Vi maduraron junto a la virtualización. Los proveedores de hardware invirtieron mucho porque la asignación segura de dispositivos a VMs lo exigía.
5. “Grupos IOMMU” están moldeados por la topología PCIe. El agrupamiento no es un capricho de Linux; refleja qué dispositivos pueden aislarse dado puentes, ACS y enrutamiento.
6. Thunderbolt popularizó PCIe externo para consumidores. Genial para docks y eGPUs; también un vector DMA en bandeja de regalo si no lo controlas.
7. Las fallas de DMA pueden ser oro diagnóstico. En producción, los logs de fallas de IOMMU han detectado bugs de drivers que de otro modo parecían errores aleatorios de RAM.
8. Algunos sistemas se enviaron durante años con IOMMU desactivada por defecto. Las preocupaciones de compatibilidad y rendimiento eran reales; también lo era la deuda de seguridad.
9. Los kernels modernos soportan características de protección DMA por dispositivo. El kernel puede elegir comportamiento estricto o perezoso de mapeo, y algunos dispositivos pueden ejecutarse en “passthrough” mientras otros están aislados.

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana operaba un clúster de virtualización privado para cargas de CI. Los desarrolladores podían crear VMs con passthrough de GPU
para acelerar compilaciones y algunas pruebas ML. El equipo de plataforma asumió que, porque los hosts estaban en un rack seguro y las VMs eran “internas”,
el riesgo principal era vecinos ruidosos y costo.

Un investigador del equipo de seguridad hizo lo que hacen los buenos investigadores: preguntó “¿y si la VM es hostil?” Obtuvieron aprobación para probar en un entorno de staging que
reproducía el hardware de producción. En staging, hicieron passthrough de una NIC de repuesto a un invitado para probar el comportamiento SR-IOV. El invitado pudo hacer DMA
en la memoria del host. No siempre. No de forma fiable. Pero lo suficiente para demostrar la lectura de estructuras que nunca deberían cruzar esa frontera.

La causa raíz no fue exótica. La BIOS tenía “Intel VT-d” disponible pero desactivada. Los documentos de aprovisionamiento decían “habilitar VT-x”
para virtualización, y alguien asumió que VT-x implicaba VT-d. No lo hace. Puedes ejecutar VMs bien sin aislamiento de DMA de dispositivos, hasta que haces passthrough o conectas algo malicioso.

La solución fue directa: habilitar VT-d, aplicar IOMMU en el kernel y actualizar la línea base de la plataforma para que falle despliegues que no lo tengan. La parte dolorosa fue la auditoría:
tuvieron que revalidar todo el clúster, porque “asumimos que estaba activado” no es evidencia.

La lección que quedó: si operas infraestructura virtualizada y alguna vez planeas hacer passthrough, SR-IOV o algo “cercano al hardware”, trata “IOMMU habilitada y estricta” como requisito duro, no como un ajuste.

Mini-historia 2: La optimización que salió mal

Otra empresa ejecutaba analítica de trading sensible a la latencia en bare metal con NICs especializadas. Les importaban los microsegundos como al resto del mundo le importa el oxígeno.
Durante un impulso de rendimiento, alguien propuso habilitar un modo “IOMMU passthrough” a nivel del sistema, argumentando que la IOMMU “solo añade sobrecarga de traducción” y que
los sistemas estaban físicamente seguros de todas formas.

Probaron el throughput y vieron pequeñas mejoras en un benchmark sintético. Celebración. El cambio se desplegó más ampliamente. Unos días después, aparecieron fallos esporádicos:
panic del kernel, sk_buffs corruptos, quejas extrañas del asignador. Parecía RAM mala. Olía a driver defectuoso. Se reproducía solo bajo tráfico pico.

La causa real fue mundana y brutal: un bug del driver programaba ocasionalmente un mapeo DMA incorrecto bajo una condición rara de desbordamiento. Con IOMMU estricto, el DMA fuera de límites
habría fallado. En modo passthrough, escribió en memoria adyacente y convirtió un bug recuperable en corrupción silenciosa.

Revirtieron la “optimización” y los fallos cesaron. Después trabajaron con el proveedor para arreglar el driver y re-benchmar con mapeos más estrictos pero páginas IOVA más grandes y mejor dimensionado de colas.
Recuperaron la mayor parte del rendimiento sin convertir el sistema de memoria en un caos.

La lección: la IOMMU no es solo una característica de seguridad. Es el cinturón de seguridad del DMA. Desactivarla puede hacer el coche más rápido en una recta. Hasta que chocás con la realidad.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización sanitaria tenía una política: cada línea de comandos del kernel se gestionaba centralmente, y cada log de arranque se raspaba en busca de firmas específicas. Una de esas firmas era “IOMMU enabled” y “DMAR: IOMMU enabled” (Intel) o “AMD-Vi: IOMMU enabled” (AMD). Si no estaba, el host quedaba en cuarentena para cargas sensibles.

Durante una renovación de hardware de rutina, llegó un lote de servidores con valores por defecto de BIOS diferentes a la generación anterior. Los hosts arrancaron. Se unieron al inventario. Pasaron chequeos básicos de salud. Pero el raspador de logs marcó la falta de habilitación de IOMMU en un subconjunto.

La reacción inmediata del equipo de proyecto fue de molestia. “Están en el mismo datacenter seguro.” “No usamos Thunderbolt.” “Lo arreglamos después.” El SRE de guardia dijo no, porque el punto de las líneas base es que no se negocian a las 2 a.m. Detuvieron el despliegue y ajustaron la BIOS antes de mover cargas.

Dos semanas después, un contratista fue sorprendido conectando un dispositivo PCIe no autorizado a una máquina de laboratorio en otro entorno. Ese incidente no afectó producción, pero fue un recordatorio de que las suposiciones físicas se degradan con el tiempo. La comprobación aburrida del log evitó que una clase de fallos “no pensamos que importaba” llegara a sistemas regulados.

La lección: no se gana fiabilidad con heroísmos. Se gana con automatización aburrida que no se negocia.

Tareas prácticas: comandos, salidas y decisiones

A continuación tienes comprobaciones prácticas que puedes ejecutar en sistemas Linux. Cada tarea incluye: un comando, qué significa una salida típica,
y la decisión que tomas. No son académicas; son los pasos exactos que usas cuando alguien pregunta “¿Está la IOMMU activada?” o “¿Por qué falla VFIO?” o “¿Por qué la NIC se cuelga bajo carga?”

Tarea 1: Verificar parámetros de arranque del kernel para habilitación de IOMMU

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.8.0 root=/dev/mapper/vg0-root ro quiet intel_iommu=on iommu=pt

Qué significa: intel_iommu=on solicita Intel VT-d. iommu=pt es “passthrough”
para dispositivos que no usan mapeos de la API DMA (a menudo una elección de rendimiento).

Decisión: Si estás protegiendo contra DMA, evita iommu=pt a nivel del sistema a menos que entiendas
qué dispositivos estarán en passthrough y por qué. Prefiere traducción estricta/por defecto cuando el modelo de amenaza incluye dispositivos hostiles.

Tarea 2: Confirmar que la IOMMU se inicializó (Intel DMAR)

cr0x@server:~$ dmesg | grep -E 'DMAR|IOMMU'
[    0.842113] DMAR: IOMMU enabled
[    0.842981] DMAR: Host address width 46
[    0.843540] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.848992] DMAR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[    0.850220] DMAR: Interrupt remapping enabled

Qué significa: Quieres ver “IOMMU enabled” y, idealmente, “Interrupt remapping enabled.” El remapeo de interrupciones importa porque MSI/MSI-X también puede ser abusado; el remapeo reduce ese radio de daño.

Decisión: Si falta, no estás protegido. Arregla ajustes de BIOS/UEFI primero y luego parámetros del kernel.

Tarea 3: Confirmar que la IOMMU se inicializó (AMD-Vi)

cr0x@server:~$ dmesg | grep -E 'AMD-Vi|IOMMU'
[    0.611234] AMD-Vi: IOMMU performance counters supported
[    0.611290] AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
[    0.611542] AMD-Vi: Extended features (0xf77ef22294ada): PPR NX GT IA GA PC GA_vAPIC
[    0.611910] AMD-Vi: Interrupt remapping enabled

Qué significa: La IOMMU de AMD está activa y el remapeo de interrupciones está encendido.

Decisión: Si no lo ves, considera el host como no conforme para passthrough y para entornos físicos de alto riesgo.

Tarea 4: Comprobar si la vista del sistema de archivos de IOMMU está presente

cr0x@server:~$ ls -1 /sys/kernel/iommu_groups | head
0
1
10
11
12

Qué significa: Existen grupos IOMMU. Eso es una buena señal, aunque no una garantía completa de modo estricto.

Decisión: Si esta ruta no existe, o no tienes IOMMU habilitada, o tu kernel/config lo oculta. Investiga antes de intentar VFIO.

Tarea 5: Listar dispositivos y sus grupos IOMMU (planificación de passthrough)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group ${g##*/}"; lspci -nns $(basename -a $g/devices/*); echo; done
Group 7
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:7a06]

Group 8
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684]
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:22ba]

Qué significa: Tu GPU y su función de audio HDMI están en el mismo grupo. Eso es normal. Si tu GPU
comparte grupo con dispositivos aleatorios del chipset, es una bandera roja para aislamiento en passthrough.

Decisión: Pasa a través solo grupos completos. Si el agrupamiento es muy grueso, considera diferentes ranuras,
habilitar ACS en la BIOS o cambiar hardware. Evita “parches de anulación de ACS” en producción a menos que comprendas las compensaciones de seguridad.

Tarea 6: Verificar que VFIO usa un dominio IOMMU para un dispositivo pasado

cr0x@server:~$ dmesg | grep -E 'vfio|IOMMU' | tail -n 20
[  124.332910] vfio-pci 0000:01:00.0: enabling device (0000 -> 0003)
[  124.341210] vfio_iommu_type1: DMA mapping enabled
[  124.341985] vfio_pci: add [10de:2684[ffffffff:ffffffff]] class 0x000000/00000000

Qué significa: vfio_iommu_type1 indica que el backend IOMMU de VFIO está en uso, mapeando DMA para el invitado.

Decisión: Si VFIO se queja de que no hay IOMMU, no la “forces”. Arregla la configuración de la plataforma. De lo contrario estás construyendo una sala de escape sin paredes.

Tarea 7: Comprobar si el kernel está en modo DMA estricto o usa mapeo perezoso

cr0x@server:~$ cat /sys/module/iommu/parameters/strict
Y

Qué significa: El modo estricto está habilitado (desmapado inmediato, protección más estricta, a veces mayor sobrecarga).
En algunos sistemas puedes ver N, indicando desmapado diferido/perezoso.

Decisión: Para hosts sensibles en seguridad, prefiere estricto. Para appliances de puro rendimiento en entornos controlados,
puedes aceptar no estricto si entiendes el riesgo y mides la ganancia.

Tarea 8: Detectar fallos de IOMMU (la señal de “tu dispositivo intentó algo ilegal”)

cr0x@server:~$ dmesg | grep -i -E 'DMAR:.*fault|IOMMU.*fault|AMD-Vi:.*event' | tail -n 20
[ 9231.112233] DMAR: DRHD: handling fault status reg 2
[ 9231.112241] DMAR: [DMA Read] Request device [01:00.0] fault addr 0x0000000f3a200000 [fault reason 0x06] PTE Read access is not set

Qué significa: Un dispositivo intentó leer por DMA una dirección sin permiso. Esto puede ser un ataque, un bug de driver,
o una carrera de reset del dispositivo.

Decisión: Trata fallos repetidos como un incidente. Identifica el dispositivo, actualiza drivers/firmware y considera retirarlo de servicio.
Si es un único evento durante reset, correlaciona con logs y eventos hardware.

Tarea 9: Identificar un dispositivo por BDF y mapearlo a un driver

cr0x@server:~$ lspci -s 01:00.0 -nnk
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:5123]
	Kernel driver in use: vfio-pci
	Kernel modules: nvidiafb, nouveau

Qué significa: El dispositivo en 01:00.0 está ligado a vfio-pci. Eso implica que pretendes asignarlo.

Decisión: Si no querías asignarlo, corrige el enlace del driver. Si sí, asegúrate de que el grupo esté aislado y que el invitado esté configurado correctamente.

Tarea 10: Comprobar si el remapeo de interrupciones está activo (seguridad + estabilidad)

cr0x@server:~$ dmesg | grep -i 'remapping' | head
[    0.850220] DMAR: Interrupt remapping enabled
[    0.850232] DMAR-IR: Enabled IRQ remapping in x2apic mode

Qué significa: El remapeo de IRQ está habilitado; esto ayuda a contener dispositivos que pueden generar interrupciones de maneras inesperadas.

Decisión: Si no está habilitado, verifica ajustes de BIOS y parámetros del kernel. Algunas plataformas lo desactivan cuando están mal configuradas; arregla eso antes de confiar en passthrough.

Tarea 11: Confirmar que existe un controlador Thunderbolt y cómo se autoriza

cr0x@server:~$ lspci | grep -i thunderbolt
3d:00.0 USB controller: Intel Corporation Thunderbolt 4 NHI [Maple Ridge]

Qué significa: Tienes un controlador Thunderbolt. Ese es un punto de ingreso PCIe externo.

Decisión: En laptops/estaciones de trabajo, combina IOMMU con políticas de seguridad de Thunderbolt. En servidores, considera deshabilitar puertos PCIe externos si no los necesitas.

Tarea 12: Comprobar estado de kernel lockdown / Secure Boot (ayuda a hacer cumplir políticas, no es la IOMMU en sí)

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity

Qué significa: El lockdown del kernel está en modo de integridad (común con Secure Boot). Esto puede reducir la capacidad
de root para hacer ciertas acciones riesgosas, como acceso arbitrario a memoria del kernel.

Decisión: No confundas esto con protección DMA. Es complementario. Manténlo activado para cargas de alta confianza, pero sigue verificando la IOMMU.

Tarea 13: Inspeccionar DMA mask / capacidad de direccionamiento (ayuda a explicar fallos de mapeo)

cr0x@server:~$ cat /sys/bus/pci/devices/0000:01:00.0/dma_mask_bits
64

Qué significa: El dispositivo puede hacer DMA a direcciones de 64 bits. Los dispositivos limitados a 32 bits pueden causar bounce buffering
y problemas de rendimiento, y aumentan la presión en zonas de memoria baja.

Decisión: Si ves 32-bit en un dispositivo de alto rendimiento, espera sobrecarga. Considera reemplazo de hardware, o estrategias de pin/bounce según tu stack.

Tarea 14: Comprobar hugepages (ajuste de rendimiento para cargas DMA-intensas)

cr0x@server:~$ grep -E 'HugePages|Hugepagesize' /proc/meminfo
HugePages_Total:      2048
HugePages_Free:       1980
HugePages_Rsvd:         12
Hugepagesize:        2048 kB

Qué significa: Se configuraron hugepages de 2MB. Las páginas grandes pueden reducir la sobrecarga de mapeo IOMMU al disminuir el número
de traducciones IOVA necesarias para buffers grandes.

Decisión: Si luchas con misses en IOTLB o alta sobrecarga de mapeo DMA, considera hugepages—pero solo después de medir y asegurarte de que tu aplicación se beneficie.

Tarea 15: Monitorizar mensajes del kernel relacionados con IOMMU en vivo durante resets de dispositivo

cr0x@server:~$ journalctl -k -f
Feb 04 12:11:19 server kernel: vfio-pci 0000:01:00.0: Resetting device
Feb 04 12:11:19 server kernel: DMAR: [DMA Write] Request device [01:00.0] fault addr 0x0000000f3a210000 [fault reason 0x05] PTE Write access is not set

Qué significa: Estás viendo fallos durante el reset. Algunos dispositivos se comportan mal mientras transicionan.

Decisión: Si los fallos se correlacionan estrechamente con operaciones de reset y luego cesan, documenta y valida con la guía del proveedor. Si continúan, trátalo como malfuncionamiento o compromiso.

Chiste #1: Un dispositivo PCIe sin IOMMU es como darle la llave maestra de tu apartamento a tu niño pequeño. “Ayudarán” de forma creativa.

Guion de diagnóstico rápido

Cuando algo huele raro—errores VFIO, corrupción aleatoria, caídas inesperadas de rendimiento—no explores durante horas. Usa una
secuencia que reduzca rápidamente el dominio de fallo. Aquí está el guion que tengo en la cabeza.

Primero: ¿la IOMMU está realmente habilitada y haciendo cumplir políticas?

• Revisa /proc/cmdline en busca de intel_iommu=on o amd_iommu=on, y cuidado con valores riesgosos como iommu=pt.
• Revisa dmesg en busca de “IOMMU enabled” y “Interrupt remapping enabled.”
• Comprueba que /sys/kernel/iommu_groups/ exista.

Si faltan, para. Arregla firmware + parámetros del kernel. Todo lo demás es ruido.

Segundo: ¿el aislamiento de tu dispositivo es real (grupos y topología)?

• Lista grupos IOMMU y confirma que tu dispositivo objetivo no esté agrupado con dispositivos no relacionados.
• Verifica si ACS está presente/funciona; si no, no finjas que tienes aislamiento.

Si el agrupamiento es demasiado burdo, tu “plan de passthrough” es un plan para compartir límites de confianza.

Tercero: ¿hay fallos de IOMMU o errores de mapeo?

• Busca en logs fallos DMAR/AMD-Vi.
• Si hay fallos: identifica el dispositivo por BDF, verifica versiones de driver y firmware, correlaciona con resets y picos de carga.

Fallos frecuentes no son “normales.” Son o un bug, o una mala configuración, o un dispositivo que debería retirarse.

Cuarto: si la queja es rendimiento, mide el punto de presión real

• Comprueba si usas hugepages donde tiene sentido.
• Confirma la DMA mask del dispositivo (limitaciones de 32-bit causan bounce buffering).
• Confirma ajustes de estrictitud de IOMMU y considera ajuste dirigido en lugar de passthrough global.

Errores comunes: síntoma → causa raíz → solución

Estos son patrones que veo repetidamente, incluso en entornos “maduros”. La mayoría son evitables si tratas la IOMMU como parte de tu línea base, no como un proyecto especial.

1) VFIO dice “No IOMMU detected”

Síntoma: El passthrough de VM falla; los logs se quejan de falta de soporte de IOMMU.

Causa raíz: VT-d/AMD-Vi deshabilitado en BIOS/UEFI, o parámetros de arranque del kernel ausentes/incorrectos.

Solución: Habilita VT-d/AMD-Vi en firmware; añade intel_iommu=on o amd_iommu=on; verifica vía dmesg que se inicializó.

2) El passthrough funciona, pero el aislamiento es falso

Síntoma: Puedes asignar un dispositivo, pero comparte un grupo IOMMU con componentes del chipset u otros dispositivos.

Causa raíz: La topología PCIe no soporta aislamiento (sin ACS, o puertos downstream compartidos).

Solución: Usa ranuras distintas, añade switches PCIe con soporte ACS, o cambia la plataforma. No uses hacks de anulación de ACS como “seguridad”.

3) Corrupción aleatoria de memoria bajo carga I/O intensa

Síntoma: Kernel panics, corrupción del asignador, fallos extraños que parecen RAM defectuosa.

Causa raíz: La IOMMU en modo passthrough/identidad enmascara bugs de DMA; el dispositivo escribe fuera de límites.

Solución: Habilita IOMMU estricto; actualiza driver/firmware; reduce ajustes agresivos que aumentan condiciones de carrera (profundidad de colas, tormentas de reset).

4) El arranque cuelga o dispositivos desaparecen al habilitar IOMMU

Síntoma: El sistema se vuelve inestable tras habilitar IOMMU; algunos dispositivos no inicializan.

Causa raíz: Bugs de firmware, kernels antiguos o dispositivos que asumen mapeo por identidad.

Solución: Actualiza BIOS/UEFI; actualiza el kernel; considera quirks por dispositivo en lugar de desactivar IOMMU globalmente. Si un dispositivo no puede coexistir con IOMMU, cuestiona ese dispositivo.

5) “Habilitamos IOMMU, así que Thunderbolt es seguro”

Síntoma: La revisión de seguridad aprueba el riesgo de Thunderbolt sin comprobar políticas de autorización del SO.

Causa raíz: Confundir aislamiento DMA con autorización de dispositivos. La IOMMU restringe memoria, pero no decide quién puede entrar al bus.

Solución: Aplica niveles de seguridad de Thunderbolt y políticas de autorización del SO; deshabilita puertos PCIe externos cuando no sean necesarios; mantén la IOMMU activada.

6) Regresión de rendimiento atribuida a IOMMU sin pruebas

Síntoma: Caídas de throughput; alguien sugiere iommu=pt o desactivar IOMMU.

Causa raíz: Cuello de botella no medido: mapeos de páginas pequeños, misses IOTLB, DMA mask de 32-bit, o tamaños de cola subóptimos.

Solución: Mide primero; usa hugepages donde corresponda; afina por dispositivo; mantén la aplicación para el resto.

Chiste #2: Desactivar la IOMMU para “mejorar el rendimiento” es como quitar los frenos para “reducir peso.” Funciona hasta que deja de hacerlo.

Listas de verificación / plan paso a paso

Lista de endurecimiento básica (flota / datacenter)

1. Firmware: Habilita VT-d (Intel) o AMD-Vi (AMD). Habilita remapeo de interrupciones si se selecciona por separado.
2. Línea de comandos del kernel: Establece intel_iommu=on o amd_iommu=on. Evita iommu=pt global a menos que tengas razones y una lista de excepciones.
3. Verificación: Aplica una comprobación en tiempo de arranque: dmesg contiene “IOMMU enabled” y “Interrupt remapping enabled.”
4. Inventario: Recopila mapas de grupos IOMMU por SKU de hardware. Guárdalos como parte del conocimiento de plataforma.
5. Cuarentena: Hosts sin IOMMU activada no ejecutan cargas que requieran passthrough, SR-IOV o aislamiento de memoria de alta confianza.
6. Registro: Alerta sobre fallos IOMMU repetidos, no sobre ruido aislado. La repetición huele a bug real.

Lista para estaciones de trabajo seguras (Thunderbolt / docks / eGPU)

1. Habilita IOMMU en firmware y verifícalo vía logs.
2. Bloquea puertos PCIe externos cuando sea posible al viajar o estar en entornos hostiles.
3. Usa políticas de autorización de dispositivos para Thunderbolt; no confíes automáticamente en periféricos nuevos.
4. Asume que estados de suspensión/hibernación pueden cambiar el panorama de amenazas. Valida la postura en suspend/resume.
5. Si manejas secretos (claves, credenciales), considera funciones de cifrado de memoria si están disponibles—pero no las trates como sustituto de la IOMMU.

Plan paso a paso para virtualización / VFIO (hazlo correctamente)

1. Demuestra que la IOMMU está habilitada: revisa /proc/cmdline y dmesg.
2. Mapea grupos IOMMU: asegura que el dispositivo objetivo esté en un grupo limpio que puedas pasar completo.
3. Vincula el dispositivo a vfio-pci: confirma con lspci -nnk.
4. Inicia la VM: observa journalctl -k -f para errores VFIO e IOMMU.
5. Valida comportamiento bajo carga: ejecuta estrés I/O; vigila fallos DMAR/AMD-Vi.
6. Decide la estrictitud: mantén modo estricto para seguridad y corrección; relaja solo si has medido y tienes controles compensatorios.

Preguntas frecuentes

1) Si tengo cifrado de disco completo, ¿por qué importan los ataques DMA?

El cifrado de disco protege datos en reposo. Los ataques DMA apuntan a datos en RAM: bloques de disco descifrados en cache, claves de sesión,
credenciales, estructuras del kernel. Si el sistema está en ejecución, la RAM es el premio.

2) ¿Habilitar la IOMMU ralentiza mi sistema?

Puede, dependiendo de la carga y del dispositivo. Para muchas cargas generales, la sobrecarga es pequeña. Para NICs de alto rendimiento o
aceleradores especializados, puedes ver un coste medible si los mapeos churnean o si usas páginas pequeñas. Mide antes de entrar en pánico y ajusta antes de desactivar.

3) ¿Cuál es la diferencia entre VT-x/AMD-V y VT-d/AMD-Vi?

VT-x/AMD-V son extensiones de virtualización de CPU (ejecutar código invitado eficientemente). VT-d/AMD-Vi son extensiones de virtualización de E/S
(contener DMA de dispositivos y permitir asignación segura de dispositivos). A menudo necesitas ambas, pero no son el mismo interruptor.

4) ¿Es “iommu=pt” seguro?

Es una compensación. A menudo significa que los dispositivos usan mapeos de identidad por defecto, lo que puede reducir la sobrecarga pero también disminuir
el contención para dispositivos que no usan la API DMA de forma controlada. En hosts sensibles en seguridad, prefiere comportamiento estricto/por defecto
y aplica passthrough solo donde lo puedas justificar.

5) ¿Qué son los grupos IOMMU y por qué debería importarme?

Los grupos representan el conjunto mínimo de dispositivos que pueden aislarse entre sí según el enrutamiento hardware y ACS.
Si dos dispositivos comparten grupo, debes asumir que no pueden separarse de forma segura para passthrough. Si ignoras esto,
estás construyendo un límite de seguridad basado en esperanza.

6) ¿Puede un dispositivo PCIe malicioso eludir una IOMMU habilitada?

No en el sentido directo de “hacer DMA a cualquier sitio”, asumiendo hardware y configuración correctos. Pero aún puedes perder si:
mapéas demasiada memoria al dispositivo, un bug de firmware de plataforma socava el aislamiento, o el atacante explota búferes permitidos y fallos lógicos de alto nivel. La IOMMU reduce el radio de daño; no reemplaza la disciplina de diseño.

7) ¿También necesito remapeo de interrupciones?

Sí cuando esté disponible. El DMA es el riesgo obvio, pero las interrupciones son otro canal por el que los dispositivos pueden afectar al sistema.
El remapeo de interrupciones ayuda a prevenir que dispositivos apunten a vectores de interrupción inesperados. Es parte seguridad, parte estabilidad.

8) ¿Por qué veo fallos de IOMMU durante el reset de un dispositivo?

Algunos dispositivos realizan transacciones tipo DMA o escrituras obsoletas durante transiciones de reset. Una IOMMU estricta puede detectarlas.
Si son raras y están estrechamente correlacionadas con resets, puede ser una peculiaridad conocida. Si se repiten bajo carga, trátalo como bug
o mala configuración y escala.

9) ¿SR-IOV es seguro sin IOMMU?

No lo hagas. SR-IOV expone funciones virtuales que pueden hacer DMA. La IOMMU es parte del modelo de seguridad que impide que los inquilinos
se toquen entre sí y toquen el host.

10) ¿Cómo se relaciona esto con funciones de cifrado de memoria?

El cifrado de memoria (dependiente de la plataforma) puede reducir el valor de contenido de RAM robada en algunos escenarios, pero el DMA todavía
puede usarse para corromper memoria, y el cifrado puede no cubrir todos los caminos DMA o buffers visibles para dispositivos como asumes.
Mantén la IOMMU como línea base en cualquier caso.

Próximos pasos que puedes hacer esta semana

No necesitas un laboratorio, una reunión de presupuesto ni una iniciativa de seguridad de tres meses para mejorar la postura frente a DMA. Necesitas unas pocas
comprobaciones aburridas y la voluntad de aplicarlas.

1. Escoge tres máquinas representativas (servidor, estación de trabajo, host de virtualización) y ejecuta las tareas prácticas arriba. Guarda las salidas.
2. Estandariza ajustes de firmware para VT-d/AMD-Vi y remapeo de interrupciones. Trata las desviaciones como incumplimiento.
3. Implementa una puerta en el log de arranque: si el kernel no declara que IOMMU y remapeo de interrupciones están habilitados, el host no ejecuta cargas sensibles.
4. Inventaría grupos IOMMU por modelo de hardware antes de comprar más de ese modelo. Si no puedes aislar lo que necesitas, estás comprando dolor futuro.
5. Decide sobre estricto vs passthrough deliberadamente. Por defecto, estricto. Permite excepciones por dispositivo solo con necesidad medida y un modelo de amenazas escrito.
6. Alerta sobre fallos IOMMU repetidos y trátalos como harías con errores ECC repetidos: el sistema te está diciendo que algo anda mal.

Si recuerdas una regla operativa: no confíes en un control de seguridad que no puedas verificar con un comando y una línea de log.
El DMA es demasiado poderoso para configuraciones basadas en sensaciones.