Thunderbolt / Risques PCIe externes : Faut-il IOMMU sur les postes de travail ?

La vraie question : un périphérique externe peut-il devenir bus master ?

« Faut-il IOMMU sur les postes de travail aussi ? » est la mauvaise première question. La bonne est :
Quelque chose que vous branchez peut-il obtenir un accès DMA à la mémoire, soit directement, soit via une chaîne de contrôleurs « utiles » ?

Thunderbolt est essentiellement du PCIe externe avec un bon service marketing. PCIe externe signifie des périphériques externes capables de faire ce que les cartes PCIe internes peuvent faire :
demander des lectures/écritures mémoire via DMA. Si vous laissez un périphérique non fiable effectuer du DMA sur votre RAM, votre OS n’a pas voix au chapitre. Ni votre antivirus. Ni votre écran de connexion. Ni le chiffrement complet du disque une fois la machine démarrée.

Ce n’est pas de la paranoïa. C’est de l’architecture. Les périphériques PCIe peuvent être bus masters. Le DMA est le fonctionnement des périphériques haut débit.
La sécurité exige que le DMA soit confiné par un IOMMU ou bloqué par une politique stricte avant le démarrage qui n’autorise jamais les périphériques non fiables sur le bus.

La fiabilité dépend aussi de cette même frontière. Des périphériques défaillants réalisant de mauvais DMA (accidentellement, pas malicieusement) peuvent corrompre la mémoire, bloquer le tissu I/O, ou déclencher des erreurs PCIe fatales qui ressemblent à des plantages « aléatoires ». En termes opérationnels : ce n’est pas aléatoire ; c’est non borné.

Ce qu’est réellement Thunderbolt (et pourquoi la sécurité s’inquiète)

Thunderbolt est un protocole de tunnellisation. Sur un seul câble physique il peut transporter PCIe et DisplayPort, plus USB et l’alimentation dans l’ère « USB-C façon ».
L’élément important est PCIe. Si vous tunnelisez PCIe, vous tunnelisez le privilège associé à PCIe.

Les contrôleurs Thunderbolt modernes et les piles OS essaient de rendre cela sensé. Il existe des niveaux de sécurité, une autorisation des périphériques, et le support du remappage DMA.
Mais c’est toujours un système de systèmes : la politique BIOS/UEFI, le firmware du contrôleur, la configuration du noyau et le comportement des pilotes doivent tous être alignés. Le moindre d’entre eux peut silencieusement réduire votre posture.

Interprétation pratique :

• Si votre poste a Thunderbolt et que vous branchez docks/eGPU/stockage : vous devriez considérer IOMMU + paramètres de sécurité Thunderbolt comme de l’hygiène obligatoire, pas du « matériel serveur uniquement ».
• Si vous n’utilisez jamais Thunderbolt, ou si vous pouvez le désactiver : le désactiver dans le firmware est souvent la réduction de risque la plus propre.
• Si votre modèle de menace inclut l’accès physique par des personnes non fiables : vous voulez des restrictions Thunderbolt pré-démarrage et une protection DMA au niveau OS. Pensez aussi aux états de veille (plus loin dans l’article).

Blague n°1 : Thunderbolt, c’est comme donner à votre portable une porte dérobée vers le tissu PCIe — parce que qu’est-ce qui pourrait mal tourner avec une porte latérale qu’on ouvre avec un câble ?

IOMMU en termes simples : ce que ça protège, ce que ça ne protège pas

Un IOMMU (Intel VT-d, AMD-Vi) est au DMA ce que l’MMU est à l’accès mémoire du CPU : une couche de traduction et de permissions.
Il peut restreindre quelles régions de mémoire physique un périphérique est autorisé à atteindre. Bien configuré, chaque périphérique (ou groupe de périphériques) obtient un bac à sable pour le DMA.

Ce que IOMMU vous apporte réellement

• Isolation DMA : un périphérique ne peut pas lire/écrire la RAM arbitrairement sauf si elle est mappée.
• Confinement des périphériques défectueux : un périphérique effectuant du DMA invalide rencontrera une faute au lieu de corrompre silencieusement la mémoire.
• Base pour le hotplug sécurisé : Thunderbolt est du hotplug. Le hotplug sans confinement DMA, c’est essentiellement « brancher et prier ».
• Virtualisation et passthrough : si vous utilisez KVM/QEMU, PCI passthrough, VFIO ou des workflows GPU conteneurisés modernes, vous voulez déjà un IOMMU configuré correctement.

Ce que IOMMU ne résout pas magiquement

• DMA avant le boot sur les systèmes qui l’autorisent : si le firmware permet à un périphérique de faire du DMA avant que l’OS configure le remappage, c’est une fenêtre d’exposition.
• Périphériques malveillants dans des mappings autorisés : si vous autorisez un périphérique Thunderbolt et que l’OS le mappe largement, le périphérique peut toujours causer des dégâts à l’intérieur de ce mapping.
• Mauvaises politiques firmware : si le BIOS/UEFI a des niveaux de sécurité permissifs, vous pouvez être compromis ou bloqué avant que l’OS n’ait son mot à dire.
• Toutes les problématiques de fiabilité : instabilités de lien, problèmes d’alimentation, câbles défectueux, retimers et bugs du firmware du contrôleur ne tiennent pas compte de votre philosophie IOMMU.

Il y a un modèle mental utile : IOMMU est nécessaire mais pas suffisant.
Vous voulez l’activer parce que c’est le seul mécanisme matériel réel pour contraindre le DMA, mais il vous faut aussi une politique : quels périphériques sont de confiance, quand et dans quelles conditions.

Une citation adaptée : L’espoir n’est pas une stratégie. (idée paraphrasée souvent entendue en ingénierie/exploitation)

Modèles de menace pour postes de travail qui comptent vraiment

La plupart des conseils en ligne pour postes de travail supposent soit (a) que vous êtes un gamer avec un eGPU, soit (b) que vous êtes un utilisateur de portable inquiet d’une attaque de type evil maid.
Les postes de production se situent dans une zone intermédiaire : ils sont parfois accessibles physiquement et ils contiennent des identifiants qui importent tout le temps.

Modèle de menace A : accès physique « réalité bureau »

Agents d’entretien, entrepreneurs, visiteurs, bureaux partagés, salles de réunion, espaces de coworking, et le classique « j’ai laissé mon portable déverrouillé deux minutes ».
Si quelqu’un peut brancher un périphérique, votre risque n’est pas théorique. Vous n’avez pas besoin d’un État-nation. Il suffit d’une personne ennuyée avec un gadget.

Modèle de menace B : docks et adaptateurs style chaîne d’approvisionnement

Le dock est « juste un dock » jusqu’à ce qu’il soit livré avec un firmware qui fait quelque chose de surprenant, ou que l’adaptateur bon marché soit en réalité un petit ordinateur.
Vous n’avez même pas besoin de malveillance ; un périphérique mal implémenté peut quand même ruiner votre journée en inondant le bus de PCIe d’erreurs.

Modèle de menace C : fiabilité et intégrité des données

Les ingénieurs stockage se préoccupent des modes de défaillance ennuyeux : corruption, réinitialisations de bus, kernel panic, et basculement silencieux en USB2 parce qu’un câble est marginal.
Le PCIe externe est rapide — et fragile. IOMMU peut prévenir certaines catégories de corruptions induites par DMA, mais ajoute aussi de la complexité qui peut se traduire par « pourquoi mon périphérique disparaît seulement quand j’active VT-d ? »

Alors faut-il IOMMU sur les postes de travail ?

Si votre poste de travail a Thunderbolt et que vous l’utilisez, activez IOMMU. Si vous avez Thunderbolt et que vous ne l’utilisez pas, désactivez Thunderbolt.
Si vous ne pouvez pas le désactiver, activez IOMMU et configurez une sécurité Thunderbolt stricte.

Les exceptions sont étroites : systèmes très anciens avec des implémentations IOMMU cassées, ou rigs audio/vidéo de niche où activer IOMMU augmente manifestement la latence — c’est rare, mais ça arrive.
Même dans ces cas, je préfère réparer le système plutôt que de l’exploiter avec « le PCIe externe peut faire du DMA sur ma mémoire » comme norme acceptée.

Faits et contexte historique utiles à connaître

1. Thunderbolt a commencé sous le nom « Light Peak », initialement pensé comme interconnexion optique avant que le cuivre l’emporte sur le coût et la puissance.
2. Thunderbolt tunnelise PCIe, ce qui explique pourquoi les eGPU et boîtiers NVMe externes peuvent sembler « aussi rapides qu’en interne » quand tout fonctionne.
3. Les attaques DMA préexistent à Thunderbolt : FireWire (IEEE 1394) exposait des problèmes similaires car il permettait aussi des accès de type DMA dans certaines implémentations.
4. La recherche « Thunderclap » (mi-2010s) a mis en lumière des chemins d’attaque DMA réels contre Thunderbolt sur des OS courants, poussant les fournisseurs à améliorer les mitigations.
5. Il existe des niveaux de sécurité dans Thunderbolt (souvent décrits SL0–SL3), allant de « pas de sécurité » à l’exigence d’autorisation et la restriction du comportement pré-démarrage.
6. Kernel DMA Protection est devenu une fonctionnalité majeure sur Windows en réponse aux risques DMA externes ; cela dépend du support matériel/firmware.
7. Linux a intégré l’autorisation Thunderbolt via le sous-système thunderbolt et des contrôles sysfs ; beaucoup de distributions par défaut adoptent des modes « autorisation utilisateur » plus sûrs lorsqu’ils sont pris en charge.
8. USB4 hérite beaucoup du modèle Thunderbolt ; le connecteur peut indiquer USB-C, mais la posture de sécurité dépend des protocoles négociés.
9. Les groupements IOMMU reflètent la topologie matérielle, pas une préférence : certaines cartes mères lient plusieurs périphériques dans un même groupe, limitant l’isolation et la sécurité du passthrough.

Trois mini-histoires d’entreprise issues du terrain

1) Incident causé par une mauvaise hypothèse : « C’est juste un dock d’écran »

Une organisation d’ingénierie de taille moyenne a déployé des docks Thunderbolt identiques pour accélérer le hot‑swap des postes. L’hypothèse était raisonnable sur le papier :
les docks sont des périphériques, et les périphériques sont peu risqués. La checklist de déploiement se concentra sur les écrans et la stabilité Ethernet, pas sur le DMA.

Quelques semaines plus tard, ils virent un schéma étrange : des développeurs signalèrent des invites d’identifiants « bizarres », et quelques machines produisirent des logs kernel
pleins d’erreurs PCIe AER juste avant un crash. La sécurité n’intervint qu’après qu’un portable montra des signes d’extraction de mémoire lors d’une revue forensique post-incident.
Personne ne pouvait prouver la malveillance, mais personne ne pouvait prouver l’innocence non plus, et c’est la définition opérationnelle d’une mauvaise journée.

La cause racine était qu’un sous-ensemble de machines était livré avec des paramètres pré-boot Thunderbolt permissifs, et IOMMU était désactivé dans le BIOS sur certains postes
en raison d’un vieux mythe interne selon lequel « VT-d nuit aux performances ». Le dock lui-même n’était probablement pas une arme ; l’environnement était juste trop confiant.
Lorsqu’on laisse la tunnelisation PCIe passer sans restriction, on mise sur la perfection de chaque mise à jour de firmware de dock.

La correction n’était pas glamour : standardiser les paramètres BIOS (activer VT-d/AMD-Vi, mettre la sécurité Thunderbolt en mode autorisation, désactiver Thunderbolt pré-boot si possible),
appliquer des politiques OS, et ajouter un « audit d’événement de branchement » à la télémétrie des endpoints. Cela n’a pas rendu les docks plus rapides. Cela a arrêté les incidents.

2) Optimisation qui s’est retournée contre eux : « Désactivez IOMMU pour moins de latence »

Une équipe de post-production vidéo avait une vraie sensibilité à la latence : interfaces audio, dispositifs de capture et lecture en temps réel. Un blog technique suggéra
de désactiver IOMMU pour réduire l’overhead. Quelqu’un a essayé, cela semblait acceptable lors d’un test rapide, et le réglage entra dans leur golden image.

Des mois plus tard, ils eurent une série de corruptions de fichiers « inexplicables » sur du stockage externe haut débit connecté via des boîtiers NVMe Thunderbolt.
Pas consistant. Non reproductible à la demande. Le pire type de corruption : celle qui apparaît après livraison quand un client vérifie les rushes.
Tout le monde blâma la marque de stockage, le fabricant de câble, et le malheureux assistant monteur pour ses « mauvaises ondes ».

La preuve apparut quand ils comparèrent les dumps de crash et les logs kernel entre les machines : les corruptions se concentraient autour des événements hotplug PCIe
et des réinitialisations de lien. Avec IOMMU désactivé, une révision de firmware défaillante d’un boîtier pouvait faire du DMA dans des endroits où elle n’aurait pas dû lors des chemins de récupération d’erreur.
Ce n’était pas une corruption garantie ; c’était de la « corruption possible ». Ce qui mène aux réunions avec le service juridique.

Réactiver IOMMU n’a pas résolu instantanément tous les problèmes de performance, mais a rendu le système plus sûr en échec : les fautes de périphérique devenaient des fautes IOMMU et des erreurs d’I/O récupérables,
pas de la corruption mémoire silencieuse. Ils s’attaquèrent ensuite aux vrais problèmes de latence : affinité IRQ, réglages d’alimentation et versions de pilotes. L’« optimisation » n’était que la suppression des garde‑fous.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : autorisation contrôlée + inventaire

Une équipe de services financiers gérait des postes développeurs qui manipulaient des identifiants de production. Ils n’étaient pas parfaits, mais disciplinés.
Thunderbolt était autorisé parce que les bureaux avaient besoin de multi-écrans et de workflows d’imagerie rapides, mais chaque périphérique devait être autorisé.

Ils se standardisèrent sur une configuration firmware : IOMMU activé, Thunderbolt en mode autorisation utilisateur, pas de périphériques pré-boot, et états de veille restreints sur les portables
pour éviter les cas limites « DMA pendant la veille ». Sur Linux, ils imposèrent une règle : les nouveaux périphériques Thunderbolt apparaissent comme non autorisés jusqu’à approbation.
Sur Windows, ils vérifiaient que Kernel DMA Protection était effectivement actif, pas seulement « supporté ».

Un après-midi, un entrepreneur branchait un dock inconnu dans un labo. La machine n’a rien monté et n’a pas planté ; elle a simplement loggé un nouveau périphérique Thunderbolt comme
présent‑mais‑non‑autorisé. Le SOC reçut une alerte depuis la télémétrie endpoint que « un nouveau périphérique PCIe externe a tenté de s’énumérer ».
La réponse fut rapide et ennuyeuse : confisquer le dock, re‑imager la machine par précaution, et revoir les images vidéos. Pas de récit de brèche, pas de drame.

Voilà à quoi ressemble le « ennuyeux » quand ça marche : un événement potentiellement dangereux devient un ticket et une checklist. Personne n’obtient une histoire de guerre. C’est l’objectif.

Mode d’urgence : goulot d’étranglement vs bug vs frontière

Quand Thunderbolt/PCIe externe est impliqué, les défaillances se ressemblent souvent : stockage lent, réseau instable, GPU qui décroche, blocages aléatoires,
et des logs pleins d’acronymes. Voici un ordre de triage qui trouve rapidement le vrai goulot.

Première étape : prouver quel lien vous avez réellement négocié

• Le périphérique est-il vraiment en Thunderbolt/PCIe, ou est‑il tombé en USB ?
• Est‑il coincé à une faible vitesse à cause d’un câble/retimer ?
• Y a‑t‑il une boucle de réapprentissage du lien PCIe ?

Deuxième étape : vérifier l’état et les fautes IOMMU/DMAR/IVRS

• IOMMU est‑il activé et opérationnel ?
• Y a‑t‑il des fautes IOMMU indiquant des DMA bloqués (bon pour la sécurité, mauvais pour la compatibilité) ?
• Les périphériques sont‑ils groupés de façon à empêcher l’isolation ?

Troisième étape : vérifier l’état de sécurité/autorisation Thunderbolt

• Le périphérique est‑il autorisé ?
• Le système est‑il dans un niveau de sécurité permissif ?
• Le comportement pré‑boot permet‑il une énumération trop précoce ?

Quatrième étape : investiguer alimentation et firmware

• Vous sous‑alimentez‑vous le port avec un boîtier bus‑powered ?
• Y a‑t‑il une révision de firmware du contrôleur connue comme problématique ?
• Utilisez‑vous un « câble mystère pris à un stand de conférence » ?

Blague n°2 : Le moyen le plus rapide de déboguer Thunderbolt est de remplacer le câble ; le deuxième plus rapide est de faire semblant de l’avoir remplacé et de perdre deux heures.

Tâches pratiques : vérifier, durcir et dépanner (avec commandes)

Les commandes ci‑dessous sont orientées Linux parce que Linux expose la vérité en clair. Windows a des équivalents (Gestionnaire de périphériques, PowerShell, journaux d’événements),
mais le workflow de diagnostic est le même : vérifier le support matériel, vérifier la politique firmware, vérifier l’application par l’OS, puis tester avec un périphérique réaliste.

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

Ce que ça signifie : « IOMMU enabled » indique que Intel VT-d est actif. Sur AMD vous verrez des lignes AMD-Vi/IVRS.
Les régions RMRR (mémoire réservée) peuvent indiquer que certains périphériques nécessitent des mappings d’identité (ce qui complique l’isolation).
Décision : Si vous ne voyez rien, ou si vous voyez « IOMMU disabled », corrigez le BIOS/UEFI et les paramètres de démarrage du noyau avant toute autre action.

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

Ce que ça signifie : VT-x est la virtualisation CPU ; ce n’est pas VT-d. Mais si VT-x est présent sur une plateforme moderne, VT-d existe souvent aussi.
Décision : Ne vous arrêtez pas là. Vérifiez toujours VT-d/AMD-Vi dans le firmware et avec 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

Ce que ça signifie : intel_iommu=on force VT-d ; amd_iommu=on est l’équivalent AMD.
iommu=pt active les mappings passthrough pour la performance dans certains cas, mais peut réduire les bénéfices d’isolation pour les périphériques non explicitement remappés.
Décision : Pour des postes avec Thunderbolt et posture de sécurité, préférez le remappage complet (omettre iommu=pt) sauf raison mesurée.

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

Ce que ça signifie : « authorized » signifie que l’OS l’a permis. « stored: yes » indique que l’autorisation est mémorisée.
Décision : Dans des environnements à risque élevé, définissez la politique sur manuel et limitez les périphériques stockés. Si des périphériques inconnus apparaissent, traitez‑les comme un incident.

Task 5: Inspect Thunderbolt security level exposed by the kernel

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

Ce que ça signifie : Les valeurs communes incluent none, user, et parfois secure.
« user » requiert typiquement l’autorisation des nouveaux périphériques.
Décision : S’il est à none sur une machine utilisée en espaces partagés, changez la sécurité BIOS/UEFI Thunderbolt et/ou la politique OS. « none » est « plug‑and‑own ».

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

Ce que ça signifie : Si vous voyez le périphérique sous USB avec UAS, vous êtes peut‑être en USB 3.x, pas en tunnellisation PCIe/NVMe.
Décision : Si les performances sont faibles, vérifiez si vous avez négocié Thunderbolt vs USB. Certains boîtiers supportent les deux et tombent silencieusement en fallback.

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]

Ce que ça signifie : Vous voyez l’interface hôte Thunderbolt (NHI) et les bridges qui représentent la hiérarchie PCIe tunnelisée.
Décision : Si votre port « Thunderbolt » n’apparaît pas du tout, suspectez une désactivation BIOS, des pilotes manquants, ou une plateforme sans véritable tunnellisation 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)

Ce que ça signifie : Le périphérique est capable de 16GT/s x4 mais tourne actuellement à 8GT/s x2. C’est une perte de débit.
Décision : Avant d’accuser IOMMU, réglez la couche physique : câble, dock, port, firmware et alimentation. Les rétrogradations de lien sont généralement des problèmes de chemin matériel.

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

Ce que ça signifie : Les erreurs corrigées peuvent être survivables mais indiquent des problèmes d’intégrité signal. « Surprise Down » est souvent une déconnexion ou un événement d’alimentation.
Décision : Si des erreurs AER corrèlent avec des blocages, traitez le dock/câble/contrôleur comme suspect. Remplacez d’abord le câble, puis mettez à jour le firmware, puis testez un autre 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]

Ce que ça signifie : Les périphériques dans le même IOMMU group ne peuvent pas être isolés les uns des autres. Certaines cartes mères regroupent une grande partie du chipset, ce qui est pénalisant.
Décision : Pour VFIO/passthrough, vous pourriez avoir besoin du support ACS ou d’un matériel différent. Pour la sécurité, les gros groupes signifient un rayon d’impact plus large si un périphérique est mappé.

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

Ce que ça signifie : Un périphérique a tenté du DMA vers une adresse non autorisée. Cela peut être un pilote bogué, une politique de remappage mal configurée, ou un périphérique hostile.
Décision : Si des fautes surviennent en usage normal avec des périphériques de confiance, mettez à jour firmware/ pilotes et examinez les paramètres du noyau. Si des fautes apparaissent après branchement de matériel inconnu, escaladez.

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

Ce que ça signifie : Vous pouvez voir les événements d’énumération en direct. Couplez cela avec boltctl pour observer si de nouveaux périphériques arrivent non autorisés.
Décision : Si des périphériques démarrent complètement fonctionnels sans autorisation dans un environnement sensible, votre niveau de sécurité Thunderbolt est trop permissif.

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

Ce que ça signifie : TRAN=pcie suggère que le noyau le voit comme un périphérique NVMe/PCIe (typique des boîtiers NVMe Thunderbolt réels).
TRAN=usb signifie stockage USB.
Décision : Si vous attendiez PCIe et que vous obtenez USB, enquêtez sur la négociation câble/port et le mode du boîtier.

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

Ce que ça signifie : C’est un bon chiffre pour un NVMe externe rapide sur beaucoup d’installations Thunderbolt. Si vous voyez 300–500MB/s, vous êtes peut‑être en mode USB ou en lien rétrogradé.
Décision : Utilisez les résultats fio plus l’état du lien (Task 8) pour décider si vous avez un goulot stockage ou un problème de négociation de connectivité.

Task 15: Check power management states that cause device dropouts

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

Ce que ça signifie : ASPM agressif peut déclencher des problèmes de lien sur des chemins matériels marginaux.
Décision : Si vous avez des flaps de lien/timeouts AER, testez temporairement pcie_aspm=off. Si cela corrige la stabilité, vous avez trouvé un problème de marge signal/alimentation — puis choisissez entre stabilité et économie d’énergie.

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

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

Ce que ça signifie : Secure Boot n’est pas IOMMU, mais fait partie de la « chaîne de confiance firmware→OS ». Sur des parcs hétérogènes, les machines sans Secure Boot ont souvent d’autres réglages firmware laxistes.
Décision : Si vous ne pouvez pas standardiser la posture firmware, vous poursuivrez des fantômes : une machine se comporte, une autre non, et la seule différence est un toggle BIOS que quelqu’un a changé en 2022.

Erreurs courantes : symptômes → cause racine → correction

1) « Le stockage Thunderbolt est lent, comme du SATA »

Syndromes : ~300–550MB/s, latence élevée, performances incohérentes.

Cause racine : Le boîtier a négocié le mode USB (UAS) au lieu du tunneling PCIe/NVMe, ou le lien PCIe est rétrogradé (x1/x2, GT/s plus bas).

Correction : Utilisez lsusb -t et lsblk -o TRAN pour confirmer le transport. Vérifiez le statut de lien avec lspci -vv. Changez câble/port ; mettez à jour le firmware du dock/boîtier.

2) « Blocages aléatoires lors du docking/undocking »

Syndromes : Blocage dur, écran noir, kernel panic, parfois seulement pendant le hotplug.

Cause racine : Tempêtes AER PCIe, bugs du firmware du contrôleur, ou hotplug combiné à ASPM/power management agressif.

Correction : Vérifiez journalctl -k pour les messages AER/DPC. Testez avec un câble connu bon. Définissez temporairement pcie_aspm=off. Mettez à jour BIOS et firmware du contrôleur Thunderbolt.

3) « Tout a planté après avoir activé VT-d/IOMMU »

Syndromes : Dock non reconnu, périphériques qui disparaissent, démarrage plus long, comportement étrange des pilotes.

Cause racine : Le firmware a des tables DMAR boguées, le noyau a besoin d’astuces spécifiques, ou des périphériques dépendent de mappings identité qui changent sous IOMMU.

Correction : Mettez à jour le BIOS d’abord. Consultez dmesg pour DMAR/fautes IOMMU. Testez soigneusement les paramètres du noyau (par ex. forcer IOMMU on/off selon le vendeur). Si un périphérique spécifique se comporte mal, traitez‑le comme non fiable et remplacez‑le.

4) « On a activé la sécurité Thunderbolt, mais quelqu’un peut encore utiliser n’importe quel dock »

Syndromes : Des périphériques inconnus fonctionnent immédiatement ; aucune invite/log d’autorisation.

Cause racine : Niveau de sécurité BIOS Thunderbolt réglé sur none, support pré-boot activé, ou politique OS qui n’applique pas l’autorisation.

Correction : Vérifiez /sys/bus/thunderbolt/devices/domain0/security et boltctl. Resserrez la politique firmware : désactivez Thunderbolt pré-boot, exigez l’autorisation utilisateur.

5) « eGPU fonctionne, mais les performances sont bizarres et parfois le GPU disparaît »

Syndromes : Réinitialisations GPU, timeouts de pilote, largeur PCIe réduite, déconnexions intermittentes sous charge.

Cause racine : Instabilité du lien, problèmes d’alimentation, ou saturation du contrôleur Thunderbolt sous I/O lourde combinée au trafic d’affichage.

Correction : Vérifiez largeur/vitesse du lien avec lspci -vv. Consultez les logs kernel pour AER. Assurez une alimentation suffisante, utilisez des câbles courts certifiés, et évitez de chaîner trop de dispositifs sur un port quand vous avez besoin d’une latence prévisible.

6) « On supposait que le chiffrement complet du disque rend le DMA sans importance »

Syndromes : Argument politique, pas un crash : « on est chiffré, donc on est en sécurité. »

Cause racine : Le chiffrement protège les données au repos. Une fois la machine déverrouillée, la RAM contient des clés et secrets que le DMA peut viser.

Correction : Activez IOMMU et les fonctionnalités de protection DMA ; restreignez l’autorisation Thunderbolt ; réduisez l’exposition lors des états de veille ; appliquez des politiques de verrouillage d’écran et de suspension.

Listes de contrôle / plan étape par étape

Checklist A: Durcir un poste qui utilise des docks Thunderbolt quotidiennement

1. Base firmware : activer VT-d/AMD-Vi ; activer Secure Boot si votre organisation le supporte ; mettre à jour le BIOS vers une révision connue stable.
2. Niveau de sécurité Thunderbolt : régler sur autorisation utilisateur (ou le niveau le plus strict supporté) ; désactiver Thunderbolt pré-boot si possible.
3. Application OS : sur Linux, vérifier que la sécurité Thunderbolt n’est pas none ; utiliser bolt pour gérer l’autorisation ; logger les événements de hotplug.
4. Vérification IOMMU : confirmer dans dmesg que IOMMU est activé et qu’il n’y a pas de spam continu de fautes pendant le docking normal.
5. Inventaire des périphériques : stocker et approuver seulement les docks approuvés par l’entreprise ; supprimer les autorisations obsolètes.
6. Burn‑in fiabilité : exécuter des tests de stress (fio pour stockage, charge GPU si eGPU) tout en surveillant AER et rétrogradations de lien.
7. Discpline des câbles : standardiser les câbles ; les étiqueter ; éviter les longueurs passives qui flirtent avec les marges de signal.
8. Hook réponse incident : traiter l’énumération Thunderbolt inconnue comme un signal de sécurité ; tous les signaux méritent un enregistrement, pas forcément une alerte majeure.

Checklist B: Si vous n’avez pas besoin de Thunderbolt, supprimez le problème

1. Désactiver la tunnellisation Thunderbolt/USB4 dans le BIOS/UEFI si la plateforme le permet.
2. Désactiver explicitement le support Thunderbolt pré-boot.
3. Boucher physiquement les ports sur les systèmes à haut risque (oui, vraiment) si la machine est dans des espaces non contrôlés.
4. Garder IOMMU activé quand même si vous virtualisez ou si vous tenez à isoler des périphériques internes.

Checklist C: Prendre une décision sur iommu=pt et l’optimisation des performances

1. Commencez avec le remappage IOMMU complet (pas de passthrough).
2. Mesurez : temps de boot, débit I/O, charges sensibles à la latence.
3. Si la performance est impactée de manière mesurable, testez iommu=pt sur une machine de test seulement.
4. Re‑vérifiez : fautes IOMMU, comportement d’autorisation Thunderbolt, et si votre posture sécurité correspond toujours à votre environnement.
5. Décidez : si vos postes sont exposés à un accès physique non fiable, ne sacrifiez pas les protections DMA pour de petits gains.

FAQ

1) Si je suis sur un poste fixe (pas un portable), Thunderbolt reste‑t‑il un risque DMA ?

Oui. Desktop ou portable ne change pas ce qu’est PCIe. Les postes fixes peuvent même être plus exposés car ils vivent dans des bureaux, labos et espaces partagés avec un accès aux ports facile.

2) Activer IOMMU empêche‑t‑il toujours les attaques DMA via Thunderbolt ?

Cela empêche une grande classe d’attaques en restreignant le DMA, mais seulement si la plateforme et l’OS utilisent effectivement le remappage DMA pour ces périphériques, et si la politique pré-boot n’est pas permissive.
Pensez « atténuation majeure », pas « invincibilité ».

3) Quelle est la différence entre VT-x et VT-d ?

VT-x est le support de virtualisation CPU. VT-d est l’IOMMU (remappage DMA). Les gens les confondent constamment. Vous voulez VT-d/AMD-Vi pour l’isolation DMA Thunderbolt.

4) IOMMU va‑t‑il nuire aux performances d’un poste de travail ?

Habituellement pas de manière perceptible pour des charges desktop normales. Il peut y avoir des cas limites (workflows audio/vidéo très basse latence, ou firmware bogué).
Mesurez avant d’optimiser, et ne « optimisez » pas en supprimant des garde‑fous.

5) J’ai activé VT-d et maintenant mon dock Thunderbolt est instable. Dois‑je désactiver VT-d ?

Non — du moins pas comme première action. Mettez à jour le BIOS et le firmware Thunderbolt, testez un autre câble/dock, et vérifiez dmesg pour des fautes IOMMU.
Si un dock ne fonctionne que lorsque les protections DMA sont désactivées, ce dock se dénonce lui‑même.

6) USB-C est‑il identique à Thunderbolt/USB4 ?

USB-C est une forme de connecteur. Thunderbolt et USB4 sont des protocoles qui peuvent tourner dessus. La sécurité dépend des protocoles activés et négociés.
Un port USB-C peut être « USB seulement » (risque DMA plus faible) ou plein tunneling PCIe (risque DMA plus élevé).

7) Le chiffrement complet du disque me protège‑t‑il des attaques Thunderbolt ?

Il protège les données au repos. Une fois l’OS démarré et déverrouillé, la RAM contient des secrets. Le DMA vise la RAM. Le chiffrement est nécessaire, pas suffisant.

8) La veille/hibernation change‑t‑elle le risque ?

Les états de veille peuvent étendre la fenêtre où les périphériques restent alimentés et peuvent interagir avec la mémoire ou les bus de façon surprenante.
L’hibernation (éteint, mémoire écrite sur disque) tend à être plus sûre que la veille pour les modèles de menace d’accès physique — en supposant que le chiffrement du disque est robuste et que la machine est totalement hors tension.

9) Si j’utilise seulement des docks fournis par l’entreprise, puis‑je zapper l’autorisation Thunderbolt ?

Vous pouvez, mais vous choisissez la commodité au détriment du contrôle. L’autorisation fournit une piste d’audit et bloque les événements « quelqu’un a branché un dock random ».
Dans les environnements d’entreprise, cela vaut la gêne minimale.

10) Les groupes IOMMU comptent‑ils si je n’utilise pas de passthrough VFIO ?

Ils importent toujours conceptuellement car ils reflètent comment les frontières d’isolation sont tracées dans le matériel.
Vous vous en souciez peut‑être pas aujourd’hui, mais si votre plateforme regroupe beaucoup de périphériques dans un même groupe, votre histoire de « bac à sable périphérique » est moins propre.

Prochaines étapes à faire cette semaine

Si vous traitez les postes comme des systèmes importants — parce que c’est le cas — considérez Thunderbolt et le PCIe externe comme une interface de production :
rapide, puissante, et absolument capable de ruiner votre semaine.

1. Choisissez une posture : si vous n’avez pas besoin de Thunderbolt, désactivez‑le dans le firmware. Si vous en avez besoin, activez IOMMU et exigez l’autorisation.
2. Standardisez le firmware : documentez les réglages BIOS/UEFI pour VT-d/AMD-Vi et la sécurité Thunderbolt ; faites‑les appliquer sur le parc.
3. Vérifiez avec des preuves : exécutez les vérifications dmesg/boltctl/lspci ci‑dessous et conservez les sorties comme base de référence.
4. Réglez la couche physique : arrêtez de déboguer des erreurs « aléatoires » avec des câbles au hasard. Achetez des câbles fiables, étiquetez‑les, et retirez les maudits.
5. Instrumentez la frontière : loggez les ajouts de périphériques Thunderbolt et les événements d’autorisation. Les périphériques inconnus doivent créer automatiquement un ticket.

Les postes ne sont pas des serveurs, mais ils détiennent les clefs de votre royaume. Le PCIe externe est une frontière de privilège. Agissez en conséquence.