Skip to content
Tech AI Wire

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.

Par Tech AI Wire Team

3 min de lecture

XLinkedIn
A screenshot of the Linux kernel commit "x86/bugs: Adapt SRSO mitigation to Zen6" on kernel.org's git mirror, showing its message and the three changed files.

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émentDétail
Commit« x86/bugs: Adapt SRSO mitigation to Zen6 »
AuteurBorislav Petkov (AMD)
Écrit le21 août 2026
Intégré à tip1er septembre 2026
Fichiers modifiés3
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

  1. Linux Preps For New AMD Zen 6 BTB CTX Isolation Security Feature - Phoronix
  2. x86/bugs: Adapt SRSO mitigation to Zen6 - kernel.googlesource.com

Articles liés