Riesgos de Thunderbolt/PCIe externo: ¿Necesitas IOMMU en escritorios también?

La verdadera pregunta: ¿puede un dispositivo externo convertirse en bus master?

“¿Necesito IOMMU en escritorios también?” es la pregunta errónea al principio. La correcta es:
¿Puede algo que conectes obtener acceso DMA a la memoria, ya sea directamente o a través de una cadena de controladores “útiles”?

Thunderbolt es, esencialmente, PCIe externo con un buen departamento de marketing. PCIe externo significa dispositivos externos que pueden hacer lo que las tarjetas PCIe internas hacen:
solicitar lecturas/escrituras de memoria vía DMA. Si permites que un dispositivo no confiable haga DMA en tu RAM, tu SO no tiene voz. Ni tu antivirus. Ni tu pantalla de inicio de sesión. Ni el cifrado de disco completo una vez que la máquina está en funcionamiento.

Esto no es paranoia. Es arquitectura. Los dispositivos PCIe pueden ser bus masters. DMA es cómo funcionan los dispositivos de alta velocidad.
La seguridad requiere que el DMA esté confinado por una IOMMU o bloqueado por una política estricta en prearranque que nunca permita dispositivos no confiables en el bus.

La fiabilidad también depende de este mismo límite. Dispositivos con mal funcionamiento que ejecuten DMA de forma incorrecta (accidentalmente, no maliciosamente) pueden corromper la memoria, bloquear la trama de I/O o desencadenar errores PCIe fatales que parecen “aleatorios”. En términos de producción: no es aleatorio; es sin límites.

Qué es realmente Thunderbolt (y por qué a los de seguridad les pone nerviosos)

Thunderbolt es un protocolo de túnel. Sobre un cable físico puede transportar PCIe y DisplayPort, además de USB y alimentación en la era “USB-C”.
La parte importante es PCIe. Si encapsulas PCIe, encapsulas el privilegio que viene con PCIe.

Los controladores Thunderbolt modernos y las pilas de SO intentan hacer esto sensato. Existen niveles de seguridad, autorización de dispositivos y soporte para remapeo DMA.
Pero sigue siendo un sistema de sistemas: la política del BIOS/UEFI, el firmware del controlador, la configuración del kernel del SO y el comportamiento del driver deben coincidir. Cualquiera de ellos puede degradar silenciosamente tu postura.

Aquí está la interpretación práctica:

• Si tu escritorio tiene Thunderbolt y conectas docks/eGPU/almacenamiento: debes tratar IOMMU + ajustes de seguridad de Thunderbolt como higiene obligatoria, no como “cosa de servidores”.
• Si nunca usas Thunderbolt, o puedes desactivarlo: desactivarlo en el firmware suele ser la reducción de riesgo más limpia.
• Si tu modelo de amenaza incluye acceso físico por personas no confiables: necesitas restricciones de Thunderbolt en prearranque y protección DMA a nivel del SO. También debes pensar en los estados de suspensión (más sobre eso después).

Broma #1: Thunderbolt es como darle a tu portátil una puerta lateral hacia la trama PCIe—porque ¿qué podría salir mal con una puerta lateral que puedes abrir con un cable?

IOMMU en términos sencillos: qué protege y qué no

Una IOMMU (Intel VT-d, AMD-Vi) es para DMA lo que una MMU es para el acceso CPU a memoria: una capa de traducción y permisos.
Puede restringir qué regiones de memoria física puede acceder un dispositivo. Bien implementada, cada dispositivo (o grupo de dispositivos) obtiene una caja de arena para DMA.

Lo que realmente te aporta IOMMU

• Aislamiento DMA: un dispositivo no puede leer/escribir RAM arbitraria a menos que esté mapeada.
• Contención de dispositivos defectuosos: un dispositivo que haga DMA basura provocará una falla en lugar de corromper memoria silenciosamente.
• Base para hotplug seguro: Thunderbolt es hotplug. Hotplug sin contención DMA es básicamente “conecta y reza”.
• Virtualización y passthrough: si usas KVM/QEMU, passthrough PCI, VFIO o flujos modernos de GPU en contenedores, ya necesitas IOMMU configurada correctamente.

Lo que IOMMU no resuelve mágicamente

• DMA en prearranque en sistemas que lo permiten: si el firmware permite que un dispositivo haga DMA antes de que el SO establezca el remapeo, existe una ventana.
• Dispositivos maliciosos dentro de mapeos permitidos: si autorizas un dispositivo Thunderbolt y el SO lo mapea de forma amplia, el dispositivo aún puede causar daño dentro de ese mapeo.
• Políticas de firmware deficientes: si la seguridad del BIOS/UEFI es permisiva, pueden surgirte problemas o bloqueos antes de que el SO tenga oportunidad.
• Todas las cuestiones de fiabilidad: fluctuaciones de enlace, problemas de alimentación, cables defectuosos, retimers y bugs de firmware del controlador no se ven afectados por tu filosofía IOMMU.

Hay un modelo mental útil: IOMMU es necesaria pero no suficiente.
Quieres tenerla activada porque es el único mecanismo real de hardware para limitar DMA, pero aún necesitas política: qué dispositivos son confiables, cuándo y bajo qué condiciones.

Una cita, porque aplica aquí: La esperanza no es una estrategia. (idea parafraseada atribuida frecuentemente en círculos de ingeniería/operaciones)

Modelos de amenaza en escritorios que realmente importan

La mayoría de consejos en línea sobre escritorios asume que (a) eres un gamer con eGPU o (b) eres usuario de portátil preocupado por un ataque de “maid malintencionada”.
Los escritorios de producción están en una zona intermedia: son accesibles físicamente a veces y contienen credenciales que importan todo el tiempo.

Modelo de amenaza A: acceso físico “en oficina”

Personal de limpieza, contratistas, visitantes, escritorios compartidos, salas de conferencias, espacios de coworking y el clásico “dejé mi portátil desbloqueado dos minutos”.
Si alguien puede conectar un dispositivo, tu riesgo no es teórico. No necesitas un estado-nación. Basta con una persona aburrida con un gadget.

Modelo de amenaza B: docks y adaptadores tipo cadena de suministro

El dock es “solo un dock” hasta que envía firmware que hace algo inesperado, o hasta que el adaptador barato es en realidad una pequeña computadora.
Ni siquiera necesitas malicia; un dispositivo mal implementado aún puede arruinar tu día provocando spam de errores PCIe.

Modelo de amenaza C: fiabilidad e integridad de datos

Los ingenieros de almacenamiento se preocupan por los modos de fallo aburridos: corrupción, resets de bus, kernel panics y caídas silenciosas a velocidades USB2 porque un cable es marginal.
PCIe externo es rápido—y frágil. IOMMU puede prevenir algunas categorías de corrupción inducida por DMA, pero también añade complejidad que puede manifestarse como “¿por qué mi dispositivo desaparece solo cuando activo VT-d?”

¿Así que necesitas IOMMU en escritorios?

Si tu escritorio tiene Thunderbolt y lo usas, activa IOMMU. Si tienes Thunderbolt y no lo usas, desactiva Thunderbolt.
Si no puedes desactivarlo, habilita IOMMU y establece seguridad estricta de Thunderbolt.

Las excepciones son estrechas: sistemas muy antiguos con implementaciones IOMMU rotas, o rigs de audio/video nicho donde activar IOMMU aumenta la latencia de forma demostrable—raro, pero ocurre.
Incluso entonces, prefiero arreglar el sistema antes que correrlo con “PCIe externo puede hacer DMA en mi memoria” como línea base aceptada.

Hechos y contexto histórico que vale la pena conocer

1. Thunderbolt empezó como “Light Peak”, inicialmente concebido como un interconector óptico antes de que el cobre ganara por coste y energía.
2. Thunderbolt tuneliza PCIe, por eso las eGPU y cajas NVMe externas pueden sentirse “internas-rapidas” cuando todo funciona.
3. Los ataques DMA preceden a Thunderbolt: FireWire (IEEE 1394) expuso problemas similares porque también permitía patrones de acceso tipo DMA en algunas implementaciones.
4. La investigación “Thunderclap” (mediados de 2010s) resaltó rutas de ataque DMA reales contra Thunderbolt en SO comunes, impulsando a los proveedores a mejorar mitigaciones.
5. Existen niveles de seguridad en Thunderbolt (a menudo descritos como SL0–SL3), que van desde “sin seguridad” hasta requerir autorización y restringir comportamiento en prearranque.
6. Kernel DMA Protection se convirtió en una característica importante en Windows en respuesta a riesgos DMA externos; depende de soporte de hardware/firmware.
7. Linux integró autorización Thunderbolt mediante el subsistema thunderbolt y controles en sysfs; muchas distros ahora por defecto usan modos más seguros de “autorización del usuario” cuando está soportado.
8. USB4 hereda gran parte del modelo de Thunderbolt; el conector puede decir USB-C, pero la postura de seguridad depende de qué protocolos se negocien.
9. Los grupos IOMMU son topología de hardware, no preferencia: algunas placas agrupan múltiples dispositivos en un solo grupo, limitando el aislamiento y la seguridad de passthrough.

Tres historias corporativas desde las trincheras

1) Incidente causado por una suposición equivocada: “Es solo un dock de monitor”

Una organización de ingeniería mediana desplegó docks Thunderbolt idénticos para agilizar el intercambio en escritorios. La suposición era razonable en papel:
los docks son periféricos, y los periféricos son de bajo riesgo. La lista de control del despliegue se centró en pantallas y estabilidad de Ethernet, no en DMA.

Unas semanas después, vieron un patrón extraño: los desarrolladores reportaban ocasionalmente avisos de credenciales “raros”, y algunas máquinas mostraron logs del kernel
llenos de errores PCIe AER justo antes de un crash. Seguridad intervino solo después de que un portátil mostrara señales de raspado de memoria en una revisión forense post-incidente.
Nadie pudo probar malicia, pero nadie pudo probar inocencia tampoco, y esa es la definición operativa de un mal día.

La causa raíz fue que un subconjunto de máquinas se enviaron con ajustes pre-boot permisivos de Thunderbolt, y IOMMU estaba desactivada en BIOS en algunos escritorios
debido a un viejo mito interno de que “VT-d perjudica el rendimiento”. El dock probablemente no era un arma; el entorno simplemente era demasiado confiado.
Cuando le das permiso libre a un túnel PCIe, apuestas tu flota a que cada actualización de firmware del dock será impecable.

La solución no fue glamorosa: estandarizar ajustes de BIOS (activar VT-d/AMD-Vi, poner la seguridad de Thunderbolt en modo autorización, desactivar Thunderbolt en pre-boot cuando sea posible),
aplicar políticas de SO y agregar una “auditoría de eventos de conexión” al monitoreo de endpoints. No hizo los docks más rápidos. Hizo que los incidentes cesaran.

2) Optimización que salió mal: “Apaga IOMMU para menor latencia”

Un equipo de posproducción de video tenía sensibilidad real a la latencia: interfaces de audio, dispositivos de captura y reproducción en tiempo real. Un blog técnico sugirió
desactivar IOMMU para reducir sobrecarga. Alguien lo probó, pareció bien en una prueba rápida, y la modificación se volvió parte de su golden image.

Meses después tuvieron una racha de “corrupción de archivos inexplicada” en almacenamiento externo de alta velocidad conectado vía cajas NVMe Thunderbolt.
No consistente. No reproducible a voluntad. El peor tipo de corrupción: la que aparece después de la entrega cuando un cliente revisa el material.
Todos culparon a la marca de almacenamiento, al proveedor de cables y a las “malas vibras” de un asistente.

La evidencia clave apareció cuando compararon volcados de memoria y logs del kernel entre máquinas: las corrupciones se agruparon alrededor de eventos de hotplug PCIe
y resets de enlace. Con IOMMU desactivada, una revisión de firmware defectuosa de la caja podía hacer DMA en lugares donde no debía durante rutas de recuperación de errores.
No era corrupción garantizada; era “corrupción posible”. Así se termina en reuniones con legal.

Volver a activar IOMMU no resolvió instantáneamente todas las preocupaciones de rendimiento, pero hizo que el sistema fallara de forma más segura: las fallas de dispositivo pasaban a ser fallos IOMMU y errores I/O recuperables,
no corrupción silenciosa de memoria. Luego abordaron los problemas reales de latencia: afinidad de IRQ, ajustes de energía y versiones de drivers. La “optimización” fue simplemente quitar las barandas de seguridad.

3) Práctica aburrida pero correcta que salvó el día: autorización controlada + inventario

Un equipo de servicios financieros ejecutaba escritorios de desarrollador que manejaban credenciales de producción. No eran perfectos, pero eran disciplinados.
Thunderbolt estaba permitido porque los escritorios necesitaban múltiples monitores y flujos de trabajo rápidos de clonación, pero cada dispositivo debía ser autorizado.

Estandarizaron una configuración de firmware: IOMMU activada, Thunderbolt en modo de autorización por usuario, sin dispositivos en pre-boot y estados de suspensión restringidos en portátiles
para evitar casos límite de “DMA durante la suspensión”. En Linux, aplicaron la regla: los nuevos dispositivos Thunderbolt aparecen como no autorizados hasta que un usuario o admin los aprueba.
En Windows, verificaban que Kernel DMA Protection realmente estuviera activo, no solo “soportado”.

Una tarde un contratista conectó un dock desconocido en un área de laboratorio. La máquina no montó nada ni se bloqueó; simplemente registró un nuevo dispositivo Thunderbolt como
presente-pero-no-autorizado. El SOC recibió una alerta desde la telemetría de endpoints de que “un nuevo dispositivo PCIe externo intentó enumerarse”.
La respuesta fue rápida y rutinaria: confiscar el dock, reinstalar la máquina por precaución y revisar las grabaciones de cámara. Sin narrativa de brecha, sin drama.

Así es como se ve lo “aburrido” cuando funciona: un evento potencialmente feo se convierte en un ticket y una lista de verificación. Nadie tiene una historia épica. Ese es el objetivo.

Guía rápida de diagnóstico: cuello de botella vs. bug vs. límite

Cuando Thunderbolt/PCIe externo está involucrado, las fallas a menudo se parecen: almacenamiento lento, red intermitente, caídas de GPU, congelamientos aleatorios,
y logs llenos de acrónimos. Aquí tienes un orden de triaje que encuentra el verdadero cuello de botella rápidamente.

Primero: prueba qué enlace realmente negociaste

• ¿El dispositivo está realmente en Thunderbolt/PCIe, o cayó a USB?
• ¿Está atascado a baja velocidad por problemas de cable/retimer?
• ¿Hay un bucle de retrain del enlace PCIe?

Segundo: comprueba la salud de IOMMU/DMAR/IVRS y fallos

• ¿IOMMU está activada y activa?
• ¿Hay fallos IOMMU que indiquen DMA bloqueado (bueno para seguridad, malo para compatibilidad de dispositivos)?
• ¿Los dispositivos están agrupados de forma que impide el aislamiento?

Tercero: comprueba el estado de seguridad/autorization de Thunderbolt

• ¿El dispositivo está autorizado?
• ¿El sistema está en un nivel de seguridad permisivo?
• ¿El comportamiento en prearranque permite la enumeración demasiado pronto?

Cuarto: persigue energía y firmware

• ¿Estás subalimentando el puerto con una carcasa alimentada por bus?
• ¿Existe una revisión conocida de firmware del controlador con problemas?
• ¿Estás usando “un cable misterioso de un stand de conferencia”?

Broma #2: La forma más rápida de depurar Thunderbolt es reemplazar el cable; la segunda más rápida es fingir que lo reemplazaste y perder dos horas.

Tareas prácticas: verificar, endurecer y solucionar (con comandos)

Los comandos abajo se inclinan hacia Linux porque Linux expone la verdad en texto plano. Windows tiene equivalentes (Administrador de dispositivos, PowerShell, registros de eventos),
pero el flujo de diagnóstico es el mismo: verificar soporte de hardware, verificar política de firmware, verificar aplicación por parte del SO y luego probar con un dispositivo realista.

Task 1: Check whether IOMMU is enabled in the kernel (dmesg)

cr0x@server:~$ dmesg | egrep -i 'DMAR|IOMMU|AMD-Vi|IVRS' | head -n 30
[    0.000000] DMAR: IOMMU enabled
[    0.000000] DMAR: Host address width 39
[    0.000000] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.000000] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c90780106f0462 ecap f020de
[    0.000000] DMAR: RMRR base: 0x0000000009f00000 end: 0x0000000009ffffff

Qué significa: “IOMMU enabled” indica que Intel VT-d está activo. En AMD verás líneas AMD-Vi/IVRS.
Las regiones RMRR (memoria reservada) pueden indicar que algunos dispositivos necesitan mapeos de identidad (pueden complicar el aislamiento).
Decisión: Si no ves nada, o ves “IOMMU disabled”, arregla BIOS/UEFI y parámetros de arranque del kernel antes de cualquier otra cosa.

Task 2: Confirm CPU virtualization extensions and IOMMU capability

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Vendor ID|Model name'
Vendor ID:                       GenuineIntel
Model name:                      Intel(R) Core(TM) i9-12900K
Virtualization:                  VT-x

Qué significa: VT-x es virtualización de CPU; no es VT-d. Pero si VT-x está presente en una plataforma moderna, VT-d suele existir también.
Decisión: No te quedes aquí. Verifica VT-d/AMD-Vi en firmware y en dmesg.

Task 3: Check kernel command line for IOMMU and passthrough mode

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

Qué significa: intel_iommu=on fuerza VT-d activada; amd_iommu=on es el equivalente para AMD.
iommu=pt habilita mapeos de passthrough para rendimiento en algunos casos, pero puede reducir beneficios de aislamiento para dispositivos no remapeados explícitamente.
Decisión: Para escritorios con Thunderbolt y postura de seguridad, prefiere remapeo completo (omite iommu=pt) a menos que tengas razones medidas.

Task 4: List Thunderbolt devices and their authorization status

cr0x@server:~$ boltctl
 ● Dell TB16 Dock
   ├─ type:          peripheral
   ├─ name:          Dell Thunderbolt Dock
   ├─ vendor:        Dell
   ├─ uuid:          2c1b8b50-8d41-4e1e-9f5a-5c6b0b2a1a1d
   ├─ status:        authorized
   ├─ stored:        yes
   └─ policy:        auto

Qué significa: “authorized” significa que el SO lo ha permitido. “stored: yes” significa que la autorización se recuerda.
Decisión: En entornos de alto riesgo, pon la política en manual y mantiene los dispositivos almacenados al mínimo. Si aparecen dispositivos desconocidos, trátalo como incidente, no curiosidad.

Task 5: Inspect Thunderbolt security level exposed by the kernel

cr0x@server:~$ cat /sys/bus/thunderbolt/devices/domain0/security
user

Qué significa: Valores comunes incluyen none, user y a veces secure.
“user” normalmente requiere autorización de nuevos dispositivos.
Decisión: Si es none en un sistema usado en espacios compartidos, cambia la seguridad de Thunderbolt en BIOS/UEFI y/o la política del SO. “none” es “conectar y hacerse cargo”.

Task 6: Identify whether a “Thunderbolt” enclosure is actually using USB storage mode

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 10000M

Qué significa: Si ves el dispositivo bajo USB con UAS, puede que estés usando USB 3.x, no túnel PCIe/NVMe.
Decisión: Si el rendimiento es bajo, verifica si negociaste Thunderbolt vs USB. Algunas cajas soportan ambos y caen silenciosamente a la opción más lenta.

Task 7: List PCIe devices and spot Thunderbolt controllers and bridges

cr0x@server:~$ lspci -nn | egrep -i 'thunderbolt|usb4|dsl|jhl|maple|bridge'
00:07.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [8086:1136]
00:0d.2 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [8086:1137]

Qué significa: Estás viendo la interfaz host Thunderbolt (NHI) y bridges que representan la jerarquía PCIe tunelizada.
Decisión: Si tu puerto “Thunderbolt” no aparece en absoluto, sospecha que esté deshabilitado en BIOS, drivers faltantes o una plataforma sin verdadero tunneling Thunderbolt/USB4.

Task 8: Check PCIe link speed and width for a device (performance reality check)

cr0x@server:~$ sudo lspci -s 00:07.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #9, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)

Qué significa: El dispositivo es capaz de 16GT/s x4 pero actualmente funciona a 8GT/s x2. Eso significa una reducción de throughput.
Decisión: Antes de culpar a IOMMU, arregla la capa física: cable, dock, puerto, firmware y alimentación. Las degradaciones de enlace suelen ser problemas de la ruta física.

Task 9: Look for PCIe Advanced Error Reporting (AER) spam (reliability smoking gun)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'AER|pcieport|DPC|fatal|Surprise Down' | tail -n 30
pcieport 0000:00:07.0: AER: Corrected error received: 0000:00:07.0
pcieport 0000:00:07.0: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID)
pcieport 0000:00:07.0: AER:   device [8086:1136] error status/mask=00001000/00002000
pcieport 0000:00:07.0: AER:    [12] Timeout

Qué significa: Errores corregidos pueden ser recuperables pero indican problemas de integridad de señal. “Surprise Down” suele ser una desconexión o evento de alimentación.
Decisión: Si los errores AER se correlacionan con congelamientos, trata el dock/cable/controlador como sospechoso. Cambia el cable primero, luego actualiza firmware y prueba otro dock.

Task 10: Enumerate IOMMU groups (passthrough and isolation reality)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "IOMMU Group ${g##*/}"; lspci -nns $(basename -a $g/devices/*); echo; done | head -n 40
IOMMU Group 0
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4660]

IOMMU Group 7
00:07.0 PCI bridge [0604]: Intel Corporation Thunderbolt 4 Bridge [8086:1136]
00:0d.2 USB controller [0c03]: Intel Corporation Thunderbolt 4 NHI [8086:1137]

Qué significa: Dispositivos en el mismo IOMMU group no pueden aislarse entre sí. Algunas placas agrupan la mitad del chipset, lo cual es problemático.
Decisión: Para VFIO/passthrough podrías necesitar soporte ACS o hardware diferente. Para seguridad, grupos grandes significan un radio de daño más amplio si se mapea un dispositivo.

Task 11: Check for IOMMU faults (blocked DMA attempts)

cr0x@server:~$ sudo dmesg | egrep -i 'iommu fault|DMAR:.*fault|AMD-Vi:.*Event' | tail -n 20
DMAR: [DMA Write NO_PASID] Request device [00:0d.2] fault addr 0x0000000f7c0000 [fault reason 0x05] PTE Write access is not set

Qué significa: Un dispositivo intentó DMA a una dirección no permitida. Puede ser un driver defectuoso, una política de remapeo mal configurada o un dispositivo hostil.
Decisión: Si ocurren fallos durante uso normal con dispositivos confiables, actualiza firmware/drivers y considera parámetros del kernel. Si los fallos aparecen después de conectar equipo desconocido, escala.

Task 12: Verify that Thunderbolt hotplug is mediated by authorization (udev view)

cr0x@server:~$ udevadm monitor --kernel --property
KERNEL[12345.678901] add      /devices/pci0000:00/0000:00:07.0/thunderbolt/domain0/0-0 (thunderbolt)
ACTION=add
SUBSYSTEM=thunderbolt
DEVPATH=/devices/pci0000:00/0000:00:07.0/thunderbolt/domain0/0-0
DEVNAME=/dev/thunderbolt0

Qué significa: Puedes ver eventos de enumeración en vivo. Combina esto con boltctl para observar si los nuevos dispositivos llegan como no autorizados.
Decisión: Si los dispositivos aparecen totalmente funcionales sin autorización en un entorno con conciencia de seguridad, tu nivel de seguridad Thunderbolt es demasiado permisivo.

Task 13: Confirm NVMe device path (Thunderbolt PCIe vs USB mass storage)

cr0x@server:~$ lsblk -o NAME,TRAN,MODEL,SIZE,TYPE,MOUNTPOINT
NAME        TRAN   MODEL                 SIZE TYPE MOUNTPOINT
nvme0n1     pcie   Samsung SSD 980 PRO  931G disk
nvme1n1     pcie   External NVMe        1863G disk /mnt/ext
sda         usb    USB DISK             931G disk /mnt/usb

Qué significa: TRAN=pcie sugiere que el kernel lo ve como un NVMe/PCIe (típico en cajas NVMe Thunderbolt).
TRAN=usb significa almacenamiento USB.
Decisión: Si esperabas PCIe y obtuviste USB, investiga la negociación del cable/puerto y el modo de la carcasa.

Task 14: Measure real throughput and spot throttling (storage sanity)

cr0x@server:~$ sudo fio --name=extseq --filename=/mnt/ext/testfile --size=4G --direct=1 --rw=write --bs=1M --iodepth=16 --numjobs=1 --runtime=30 --time_based
extseq: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=16
fio-3.36
...
WRITE: bw=1850MiB/s (1940MB/s), 1850MiB/s-1850MiB/s (1940MB/s-1940MB/s), io=55.3GiB (59.4GB), run=30666-30666msec

Qué significa: Esto es un número sano de “NVMe externo rápido” para muchas configuraciones Thunderbolt. Si ves 300–500MB/s, podrías estar en modo USB o con enlace degradado.
Decisión: Usa resultados de fio junto con estado del enlace (Task 8) para decidir si tratas con un cuello de botella de almacenamiento o un problema de negociación/conectividad.

Task 15: Check power management states that cause device dropouts

cr0x@server:~$ cat /sys/module/pcie_aspm/parameters/policy
powersave

Qué significa: ASPM agresivo puede provocar problemas de enlace en rutas físicas marginales.
Decisión: Si tienes flaps de enlace/tiempos de espera AER, prueba pcie_aspm=off temporalmente. Si esto mejora la estabilidad, encontraste un problema de margen de señal/energía—luego elige entre estabilidad y ahorro.

Task 16: Verify Windows-equivalent posture (from Linux side: check if firmware exposes DMA protections)

cr0x@server:~$ sudo mokutil --sb-state
SecureBoot enabled

Qué significa: Secure Boot no es IOMMU, pero forma parte de la “cadena de confianza firmware→SO”. En flotas mixtas, las máquinas con Secure Boot desactivado suelen tener también otros ajustes de firmware laxos.
Decisión: Si no puedes estandarizar la postura del firmware, perseguirás fantasmas: una máquina se comporta, otra no, y la única diferencia es un toggle de BIOS que alguien cambió en 2022.

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

1) “El almacenamiento Thunderbolt es lento, como SATA lento”

Síntomas: ~300–550MB/s, latencia alta, rendimiento inconsistente.

Causa raíz: La carcasa negoció modo USB (UAS) en lugar de túnel PCIe/NVMe, o el enlace PCIe está degradado (x1/x2, menor GT/s).

Solución: Usa lsusb -t y lsblk -o TRAN para confirmar transporte. Revisa estado de enlace con lspci -vv. Cambia cable/puerto; actualiza firmware del dock/carcasa.

2) “Congelamientos aleatorios al conectar/desconectar”

Síntomas: Bloqueo duro, pantalla negra, kernel panic, a veces solo durante hotplug.

Causa raíz: Tormentas AER de PCIe, bugs de firmware del controlador, o hotplug combinado con ASPM/agresiva gestión de energía.

Solución: Revisa journalctl -k por mensajes AER/DPC. Prueba un cable conocido bueno. Temporalmente establece pcie_aspm=off. Actualiza BIOS y firmware del controlador Thunderbolt.

3) “Todo falló después de activar VT-d/IOMMU”

Síntomas: Dock no reconocido, dispositivos desaparecen, el arranque tarda más, comportamiento extraño de drivers.

Causa raíz: Firmware con tablas DMAR bugueadas, quirks del kernel necesarios, o dispositivos que dependen de mapeos de identidad que cambian bajo IOMMU.

Solución: Actualiza BIOS primero. Revisa dmesg por fallos DMAR/IOMMU. Prueba parámetros del kernel con cuidado (por ejemplo, forzar IOMMU on/off por vendedor). Si un dispositivo específico falla, trátalo como no confiable y reemplázalo.

4) “Configuramos seguridad Thunderbolt, pero alguien aún puede usar cualquier dock”

Síntomas: Dispositivos desconocidos funcionan inmediatamente; no hay avisos/logs de autorización.

Causa raíz: Nivel de seguridad Thunderbolt en BIOS puesto en none, soporte pre-boot habilitado, o política del SO no aplicando autorización.

Solución: Revisa /sys/bus/thunderbolt/devices/domain0/security y boltctl. Endurece la política del firmware: desactiva Thunderbolt en pre-boot, requiere autorización de usuario.

5) “eGPU funciona, pero el rendimiento es raro y a veces la GPU desaparece”

Síntomas: Resets de GPU, timeouts de driver, ancho de banda PCIe reducido, desconexiones intermitentes bajo carga.

Causa raíz: Inestabilidad de enlace, problemas de suministro eléctrico, o saturación del controlador Thunderbolt bajo I/O intensivo combinado con tráfico de display.

Solución: Revisa ancho de banda/velocidad con lspci -vv. Revisa logs del kernel por AER. Asegura alimentación adecuada, usa cables cortos y certificados, y evita encadenar dispositivos por un puerto cuando necesitas latencia predecible.

6) “Asumimos que el cifrado de disco completo hace irrelevante el DMA”

Síntomas: Argumento de política, no un crash: “estamos cifrados, así que estamos seguros.”

Causa raíz: El cifrado protege datos en reposo. Una vez la máquina está desbloqueada, la RAM contiene claves y secretos que DMA puede apuntar.

Solución: Activa IOMMU y características de protección DMA; restringe autorización Thunderbolt; reduce la exposición por estados de suspensión; aplica bloqueo de pantalla y políticas de suspensión.

Listas de verificación / plan paso a paso

Checklist A: Endurecer un escritorio que usa docks Thunderbolt a diario

1. Línea base de firmware: activa VT-d/AMD-Vi; activa Secure Boot si tu organización lo soporta; actualiza BIOS a una revisión conocida y estable.
2. Nivel de seguridad Thunderbolt: configúralo en autorización por usuario (o el más estricto soportado); desactiva Thunderbolt en pre-boot cuando sea posible.
3. Aplicación en SO: en Linux, asegúrate de que la seguridad Thunderbolt no sea none; usa bolt para gestionar autorizaciones; registra eventos de hotplug.
4. Verificación IOMMU: confirma en dmesg que IOMMU está activada y que no hay spam continuo de fallos durante el acople normal.
5. Inventario de dispositivos: almacena y aprueba solo docks aprobados por la empresa; elimina autorizaciones obsoletas de dispositivos que ya no circulan.
6. Burn-in de fiabilidad: ejecuta pruebas de estrés (fio en almacenamiento, carga GPU si eGPU) mientras vigilas errores AER y degradaciones de enlace.
7. Disciplina de cables: estandariza cables; etiquétenlos; evita tramos pasivos largos que coqueteen con los márgenes de señal.
8. Gancho de respuesta a incidentes: trata la enumeración desconocida de Thunderbolt como señal de seguridad; no todas las señales son incidentes, pero todas merecen registro.

Checklist B: Si no necesitas Thunderbolt, elimina el problema

1. Desactiva tunneling Thunderbolt/USB4 en BIOS/UEFI si tu plataforma lo permite.
2. Desactiva explícitamente el soporte pre-boot de Thunderbolt.
3. Bloquea físicamente puertos en sistemas de alto riesgo (sí, en serio) si el sistema está en espacios no controlados.
4. Mantén IOMMU activada de todos modos si virtualizas o te importa aislar dispositivos internos.

Checklist C: Tomar una decisión sobre iommu=pt y ajuste de rendimiento

1. Comienza con remapeo IOMMU completo (sin modo passthrough).
2. Mide: tiempo de arranque, throughput I/O, cargas sensibles a latencia.
3. Si el rendimiento se ve afectado de forma medible, prueba iommu=pt en una máquina de pruebas solamente.
4. Vuelve a comprobar: fallos IOMMU, comportamiento de autorización Thunderbolt y si tu postura de seguridad sigue coincidiendo con el entorno.
5. Decide: si tus escritorios están expuestos a acceso físico no confiable, no sacrifiques protecciones DMA por pequeñas ganancias.

Preguntas frecuentes

1) Si estoy en un escritorio (no un portátil), ¿Thunderbolt sigue siendo un riesgo DMA?

Sí. Escritorio vs portátil no cambia lo que es PCIe. Los escritorios pueden estar incluso más expuestos porque viven en oficinas, laboratorios y espacios compartidos con acceso fácil a puertos.

2) ¿Activar IOMMU siempre previene ataques DMA por Thunderbolt?

Previene una gran clase de ataques al restringir DMA, pero solo si la plataforma y el SO realmente usan remapeo DMA para esos dispositivos, y la política de prearranque no es permisiva.
Piensa en “mitigación mayor”, no en “invencibilidad”.

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

VT-x es soporte de virtualización de CPU. VT-d es IOMMU (remapeo DMA). La gente las confunde constantemente. Necesitas VT-d/AMD-Vi para aislamiento DMA de Thunderbolt.

4) ¿IOMMU perjudicará el rendimiento en una estación de trabajo?

Usualmente no de una manera que notes en cargas de escritorio normales. Puede haber casos extremos (algunos flujos de audio/video de baja latencia, o firmware defectuoso).
Mide antes de optimizar, y no “optimices” eliminando las barandas de seguridad.

5) Activé VT-d y ahora mi dock Thunderbolt falla. ¿Debería apagar VT-d?

No—al menos no como primera medida. Actualiza BIOS y firmware del Thunderbolt, prueba con otro cable/dock y revisa dmesg por fallos IOMMU.
Si un dock solo funciona cuando las protecciones DMA están apagadas, ese dock está delatándose por sí mismo.

6) ¿USB-C es lo mismo que Thunderbolt/USB4?

USB-C es la forma del conector. Thunderbolt y USB4 son protocolos que pueden correr sobre él. La seguridad depende de qué protocolos estén habilitados y negociados.
Un puerto USB-C puede ser “solo USB” (menor riesgo DMA) o túnel PCIe completo (mayor riesgo DMA).

7) ¿El cifrado de disco completo me protege de ataques Thunderbolt?

Protege los datos en reposo. Una vez que el SO está en ejecución y desbloqueado, la RAM contiene secretos. DMA apunta a RAM. El cifrado es necesario, no suficiente.

8) ¿La suspensión/hibernación cambia el riesgo?

Los estados de suspensión pueden extender la ventana en la que los dispositivos permanecen alimentados y pueden interactuar con memoria o buses de maneras sorprendentes.
Hibernar (apagado con memoria volcada al disco) tiende a ser más seguro que la suspensión para modelos de amenaza con acceso físico—suponiendo que el cifrado del disco sea robusto y la máquina esté totalmente apagada.

9) Si solo uso docks corporativos, ¿puedo omitir la autorización Thunderbolt?

Puedes, pero estás eligiendo comodidad sobre control. La autorización provee rastro y bloquea eventos de “alguien conectó un dock al azar”.
En entornos corporativos, eso vale la fricción menor.

10) ¿Importan los grupos IOMMU si no hago passthrough VFIO?

Aún importan conceptualmente porque reflejan cómo se dibujan los límites de aislamiento en hardware.
Quizá no te importe hoy, pero si tu plataforma agrupa muchos dispositivos en un solo grupo, tu historia de “caja de arena de dispositivo” es menos limpia.

Siguientes pasos que puedes hacer esta semana

Si gestionas escritorios como si importaran—porque lo hacen—trata Thunderbolt y PCIe externo como una interfaz de producción:
rápida, potente y absolutamente capaz de arruinarte la semana.

1. Elige una postura: si no necesitas Thunderbolt, desactívalo en firmware. Si lo necesitas, activa IOMMU y exige autorización.
2. Estandariza firmware: documenta ajustes BIOS/UEFI para VT-d/AMD-Vi y seguridad Thunderbolt; hazlos cumplir en la flota.
3. Verifica con evidencia: ejecuta las comprobaciones dmesg/boltctl/lspci anteriores y guarda las salidas como parte de un registro base.
4. Arregla la capa física: deja de depurar errores “aleatorios” con cables al azar. Compra cables conocidos buenos, etiquétenlos y retira los malditos.
5. Instrumenta el límite: registra adiciones de dispositivos Thunderbolt y eventos de autorización. Dispositivos desconocidos deberían crear un ticket automáticamente.

Los escritorios no son servidores, pero contienen las llaves de tu reino. PCIe externo es un límite de privilegios. Actúa en consecuencia.