AMD Zen 6 rend inutile la mitigation SafeRET de Linux
Un correctif du noyau retire la mitigation logicielle SafeRET sur AMD Zen 6, car la puce isole les prédictions de branchement en matériel. Les attaques entre utilisateurs exigent toujours IBPB.
3 min de lecture

En chiffres
- kernel files the patch changes
- 3
- Linux version Phoronix says it targets
- 7.4
La prochaine génération de processeurs d'AMD va permettre à Linux d'abandonner l'une de ses défenses contre l'exécution spéculative. Un correctif du noyau intitulé « x86/bugs: Adapt SRSO mitigation to Zen6 » est arrivé dans l'arbre tip le 1er septembre 2026. C'est important parce que la puce fait désormais en matériel ce que le noyau faisait en logiciel. Les mitigations logicielles s'exécutent sur chaque machine concernée.
Le correctif a été écrit par Borislav Petkov, ingénieur noyau chez AMD. Il l'a rédigé le 21 août 2026 et l'a lui-même intégré le 1er septembre 2026.
L'attaque contre laquelle cela protège
Les processeurs modernes devinent quel code va s'exécuter ensuite. C'est ce qu'on appelle l'exécution spéculative. La supposition occupe la puce au lieu de la faire attendre. Quand elle est fausse, le travail est jeté.
Le problème est que ce travail jeté laisse des traces. Un attaquant capable d'orienter ces suppositions peut amener le processeur à toucher brièvement des données interdites. Il lit ensuite les traces pour en déduire le contenu. Le SRSO, pour Speculative Return Stack Overflow, est une faille de ce type. Il visait les prédictions sur le point de retour d'une fonction. Phoronix rapporte que le SRSO a touché les générations Zen 1 à Zen 4.
Linux a répondu au SRSO par une mitigation logicielle appelée SafeRET. C'est cette pièce que Zen 6 rend inutile.
Ce que Zen 6 change en matériel
Le branch target buffer est un petit cache où le processeur garde ses suppositions sur l'endroit où atterrira un saut dans le code. Si les entrées d'un programme peuvent influencer celles d'un autre, ces suppositions deviennent une surface d'attaque.
Zen 6 les sépare. « Zen6 dispose d'une protection BTB qui isole les différents contextes (utilisateur/noyau, invité/hôte) les uns des autres », indique le message du commit. Phoronix appelle cette fonction BTB CTX isolation, soit l'isolation de contexte du branch target buffer.
Cette description couvre deux frontières. L'une se situe entre un programme ordinaire et le noyau. L'autre entre l'invité d'une machine virtuelle et l'hôte qui l'exécute.
Ce que fait réellement le correctif
Le changement est petit et touche trois fichiers du code x86.
| Élément | Détail |
|---|---|
| Commit | « x86/bugs: Adapt SRSO mitigation to Zen6 » |
| Auteur | Borislav Petkov (AMD) |
| Écrit le | 21 août 2026 |
| Intégré à tip | 1er septembre 2026 |
| Fichiers modifiés | 3 |
| Noyau visé | Linux 7.4, avec 7.3 possible en correctif, selon Phoronix |
Les trois fichiers sont arch/x86/include/asm/cpufeatures.h, arch/x86/kernel/cpu/bugs.c et arch/x86/kernel/cpu/scattered.c. Le noyau détecte le nouveau comportement matériel, puis signale la situation par une nouvelle chaîne de mitigation.
Ce qui reste à la charge du logiciel
La protection matérielle ne couvre pas tout, et le commit est explicite sur ce manque.
Les attaques entre deux utilisateurs et entre deux invités ne sont pas encore traitées par la puce. Il s'agit des cas où deux programmes au même niveau de privilège, ou deux machines virtuelles, s'attaquent entre eux. Pour cela, le noyau continue de s'appuyer sur les réglages de mitigation Spectre v2 pour émettre un IBPB lors d'un changement de contexte.
IBPB signifie Indirect Branch Predictor Barrier. Cela demande au processeur de jeter les prédictions de branchement accumulées. Les prédictions d'une charge de travail ne passent donc pas à la suivante.
Ce que cela change pour les développeurs
Ne lisez pas cela comme « Zen 6 met fin aux mitigations spéculatives ». Une correction logicielle précise disparaît à deux frontières précises, et l'isolation au même niveau de privilège reste au logiciel. Si vous exécutez du code non fiable de plusieurs clients sur un même hôte, votre configuration Spectre v2 compte autant qu'avant.
Vérifiez ce que votre noyau signale plutôt que de le supposer. Le correctif ajoute une nouvelle chaîne de mitigation. Dès que vous serez sur un noyau qui porte ce changement, l'état réel de votre machine apparaîtra dans les informations du noyau lui-même.
Si vous suivez le coût des mitigations dans vos mesures, prévoyez de refaire votre référence. Des comparaisons prises sur Zen 4 avec SafeRET actif ne décrivent pas une machine Zen 6 sans lui. Les anciens chiffres ne devraient pas être repris tels quels.
Il n'y a pas non plus de matériel à tester pour l'instant. Ces sources ne donnent aucune date de sortie pour les processeurs Zen 6. Voyez-y donc une préparation du noyau, pas un changement mesurable ce trimestre. Les réglages par défaut de la protection du noyau évoluent dans les deux sens, et le coût mérite un rappel : Microsoft active l'intégrité de la mémoire de Windows 11 par défaut à partir du 13 octobre.
Sources
- Linux Preps For New AMD Zen 6 BTB CTX Isolation Security Feature - Phoronix
- x86/bugs: Adapt SRSO mitigation to Zen6 - kernel.googlesource.com
Articles liés

Un binaire strip trafiqué peut piéger tout NixOS
Des chercheurs ont construit l'attaque trusting-trust de Ken Thompson à partir de GNU strip, et non d'un compilateur, pour piéger presque tous les binaires d'un installateur NixOS.

Asahi Linux prend désormais officiellement en charge les Mac M3
Asahi Linux a intégré la prise en charge des M3, M3 Pro et M3 Max à son installateur. Le Wi-Fi, l'USB 3 et le décodage AV1 fonctionnent. La veille, le HDMI et la 3D rapide, non.

Kubernetes 1.37 fait passer le mode rootless en bêta
Kubernetes 1.37 fait passer KubeletInUserNamespace en bêta. Le kubelet, les runtimes de conteneurs, les plugins CNI et kube-proxy peuvent tous tourner en utilisateur ordinaire.