AMD réduit le coût mémoire des VM confidentielles SEV-SNP avec l’instruction RMPOPT dans Linux 7.4
L’instruction RMPOPT, attendue sur les EPYC Zen 6 « Venice », réduit la surcharge de la Reverse Map Table qui garantit l’intégrité mémoire des VM SEV-SNP, et son support Linux arrive dans le noyau 7.4. Les exploitants de VM confidentielles AMD peuvent préparer leurs bancs d’essai : le gain se joue sur les serveurs dont la RAM n’est pas saturée de machines chiffrées.
1er octobre 2026. AMD fait entrer RMPOPT, son instruction de réduction de la Reverse Map Table, dans la branche x86/sev du dépôt tip/tip.git, en vue de la fenêtre de fusion du noyau Linux 7.4. Fin octobre 2026. C’est là que s’ouvrira la fenêtre de fusion de Linux 7.4, qui accueillera le support logiciel de l’instruction. Fin décembre 2026. Le noyau 7.4 devrait sortir en version stable, si le calendrier habituel se tient. Pourquoi c’est important : le calcul confidentiel sur AMD EPYC va coûter un peu moins cher en mémoire, et c’est la première fois que cette optimisation descend jusqu’au noyau Linux.
La Reverse Map Table, le prix de l’intégrité mémoire
Pour comprendre RMPOPT, il faut d’abord comprendre ce qu’il optimise. SEV-SNP — Secure Encrypted Virtualization – Secure Nested Paging — est la réponse d’AMD au problème du « qui protège la VM du propriétaire de la machine » : il isole par le matériel une machine virtuelle de l’hyperviseur lui-même et des autres VM, si bien qu’un administrateur disposant de root sur l’hôte ne peut pas lire la mémoire d’une VM protégée.
Cette garantie a un coût, matérialisé par la Reverse Map Table, la RMP. Cette table, maintenue par le processeur, enregistre pour chaque page physique à quelle VM elle appartient et dans quel état elle se trouve — valide, chiffrée, invalide. À chaque changement d’état d’une page, le processeur doit consulter et mettre à jour la RMP, ce qui ajoute des accès mémoire et du travail de gestion aux opérations de pagination.
Le résultat est connu des exploitants de SEV-SNP : les machines confidentielles consomment davantage de ressources que leurs équivalents non protégés, parce que la RMP doit être tenue à jour en permanence. C’est la taxe de l’intégrité mémoire, acceptée jusqu’ici faute d’alternative.
RMPOPT, une instruction pour réduire la facture
RMPOPT — pour Reverse Map Table OPTimization — est précisément l’alternative. C’est une instruction processeur qu’AMD a dévoilée plus tôt dans l’année, et qui devrait faire ses débuts avec les futurs EPYC Zen 6 « Venice ».
L’idée est de réduire le travail associé à la Reverse Map Table dans les serveurs SEV-SNP. Au lieu de subir la surcharge à chaque bascule d’état de page, le processeur peut optimiser ces opérations, ce qui libère du temps CPU et de la pression mémoire pour la charge utile réelle — les VM, pas la plomberie de leur protection.
Le périmètre du gain est précis, et AMD ne le cache pas : RMPOPT « devrait s’avérer utile pour les serveurs Linux EPYC Zen 6 « Venice » où le serveur, et donc la RAM système, n’est pas saturé de VM confidentielles ». Autrement dit, l’instruction allège le surcoût des configurations raisonnables — celles où les machines chiffrées ne remplissent pas toute la mémoire — plutôt que des cas extrêmes.
Pourquoi la RMP doit rester infaillible
La RMP n’est pas une table de confort : c’est le verrou qui rend SEV-SNP crédible. Sans elle, un hyperviseur compromis — ou simplement malveillant — pourrait réaffecter ou aliaser une page mémoire appartenant à une VM, et lire ou modifier un contenu que l’isolation était censée protéger. La RMP consigne l’appartenance de chaque page au niveau matériel, si bien que toute tentative d’usurpation se traduit par un échec d’accès.
C’est aussi ce qui rend RMPOPT délicat à intégrer. Une optimisation qui touche la tenue de cette table ne peut pas se contenter d’être rapide : elle doit préserver exactement les mêmes garanties, sinon elle rejouerait le scénario qu’elle est censée empêcher. Les seize révisions des correctifs sont le symptôme de cette exigence — chaque itération a dû démontrer, devant les mainteneurs du sous-système x86, que le gain ne se paie pas en surface d’attaque.
Le contexte de marché élargit encore la portée. Face à Intel TDX, qui promet la même classe d’isolation, le calcul confidentiel se joue désormais sur deux fronts : la sécurité de l’isolation et le coût de son activation. RMPOPT est une pièce du second front — il réduit la pénalité qui dissuadait encore certains parcs de généraliser SEV-SNP.
Un feu vert Linux après seize révisions
La trajectoire logicielle raconte la maturité du travail. Les correctifs RMPOPT sont passés par seize révisions avant d’être acceptés : ils sont désormais en file dans la branche x86/sev de tip/tip.git, le dépôt de staging des changements x86 du noyau, pour être soumis à la fenêtre de fusion de Linux 7.4.
Ce nombre de révisions n’est pas anodin. Une instruction processeur nouvelle touche des chemins de code extrêmement sensibles — pagination, états mémoire, transitions entre l’hyperviseur et la VM — où une erreur corrompt l’isolation que la RMP est censée garantir. Les seize itérations traduisent un aller-retour long entre AMD et les mainteneurs du sous-système x86, jusqu’à ce que le contrat de sécurité soit jugé solide.
Le calendrier est désormais tracé. Linux 7.4 recevra RMPOPT dans sa fenêtre de fusion de fin octobre, pour une sortie stable attendue fin décembre 2026. Les distributions qui suivent de près l’amont — et les exploitants qui compilent leur propre noyau — pourront l’activer dès que le matériel Zen 6 sera disponible.
Ce que ça change, et pour qui
Le premier cercle est celui des hébergeurs cloud et des grands comptes qui exploitent le calcul confidentiel sur EPYC : la promesse est de réduire le surcoût de SEV-SNP sans toucher à ses garanties, ce qui rend l’isolation matérielle plus facile à justifier économiquement.
RMPOPT n’est pas seul dans Linux 7.4 : il arrive en même temps que PerfOpt, l’optimisation IOMMU d’AMD pour les GPU intégrés. Les deux chantiers dessinent la même direction — AMD investit dans la réduction des surcoûts de ses mécanismes de protection et de virtualisation, couche par couche.
La limite est à connaître avant de s’emballer. Le gain de RMPOPT se matérialise sur des serveurs dont la RAM n’est pas saturée de VM confidentielles, et il exige un processeur Zen 6 « Venice » — le matériel existant ne le verra pas rétroactivement. C’est une optimisation de nouvelle génération, pas un correctif pour les parcs actuels.
Un point d’attention pour les parcs qui ne compilent pas leur noyau : RMPOPT arrivera via 7.4, mais sa rétroportation vers les branches stables ou LTS des distributions n’est pas acquise. Il faudra suivre les annonces de chaque distribution plutôt que supposer une disponibilité immédiate.
Verdict
Si vous exploitez ou planifiez des VM SEV-SNP sur des EPYC Zen 6 « Venice », inscrivez RMPOPT à votre programme de validation pour Linux 7.4 : c’est le levier attendu pour réduire le surcoût mémoire du calcul confidentiel sans rien céder sur l’isolation. Si votre parc EPYC est antérieur à Zen 6, l’instruction ne vous concerne pas directement — mais surveillez la trajectoire, car elle signale que le calcul confidentiel AMD passe du stade « possible mais coûteux » au stade « à peu près gratuit ». Dans tous les cas, ne déployez pas 7.4 en production le jour de sa sortie : une instruction qui touche la RMP se teste longuement, précisément parce qu’elle protège la mémoire qu’elle optimise.