1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La prise en charge de Transparent Secure Memory Encryption (TSME) a disparu des CPU Ryzen grand public après l’arrivée d’un nouveau firmware AGESA, ce qui rend difficile pour les utilisateurs de remarquer un changement dans l’état de protection du chiffrement mémoire
  • TSME est une fonction qui chiffre toute la RAM sans intervention de l’OS afin de bloquer des attaques physiques comme les cold-boot exploits, l’espionnage de l’interface DRAM et le retrait de modules mémoire
  • D’après l’enquête GitHub de Ben Kilpatrick et des tests de contrôle réalisés par MSI, les puces Ryzen grand public activaient TSME avec les anciens firmwares, mais AGESA 1.2.7.0 l’affiche comme « not supported »
  • AMD a répondu que TSME est une « fonctionnalité de sécurité faisant partie d’AMD PRO Technologies et qui ne s’applique qu’aux CPU PRO », et un ingénieur AMD a répondu à des questions supplémentaires qu’il n’avait rien de plus à partager
  • Les utilisateurs préoccupés par les attaques avec accès physique devront choisir un système Ryzen Pro ou EPYC tant qu’AMD n’aura pas clarifié le périmètre de prise en charge ou rétabli la fonction

TSME a disparu des Ryzen grand public

  • AMD a discrètement retiré la prise en charge de Transparent Secure Memory Encryption (TSME) des CPU Ryzen grand public, ce qui pourrait rendre certains utilisateurs plus vulnérables aux attaques physiques
  • TSME est une fonction conçue pour empêcher les attaques physiques visant à extraire des données depuis les puces mémoire connectées
  • AMD a d’abord intégré cette fonction à des CPU haut de gamme avant de l’étendre aux CPU grand public, et les utilisateurs de ces puces considéraient TSME comme faisant partie du package de la puce
  • Il a été confirmé que le changement est apparu après l’arrivée d’un nouveau firmware AGESA

La découverte et la vérification de Kilpatrick

  • Ben Kilpatrick se présente comme un privacy-conscious Linux hobbyist et a exécuté Host Security ID (HSI) lors de l’installation d’un nouvel OS sur un système Ryzen 7 9700X basé sur l’architecture Zen 5
  • HSI est une fonction d’audit qui évalue la configuration de sécurité du firmware et du matériel d’un système
  • Dans les réglages du BIOS, TSME restait activé, mais HSI indiquait que TSME n’était plus pris en charge
  • Kilpatrick a d’abord contacté le constructeur de carte mère MSI sans obtenir d’explication claire, puis a déposé un rapport de bug sur le dépôt GitHub public d’ingénierie d’AMD

Un comportement différent avec AGESA 1.2.7.0

  • Tom Lendacky et Mario Limonciello d’AMD ont répondu sur GitHub, sans toutefois expliquer clairement pourquoi la fonction avait disparu
  • Les ingénieurs AMD ont conseillé d’essayer de désactiver puis réactiver l’option dans le BIOS et, si cela ne résolvait rien, d’en discuter avec le fabricant de la carte mère
  • Après une relance plus insistante de Kilpatrick auprès de MSI, les ingénieurs de MSI ont effectué des tests de contrôle
    • les puces Ryzen grand public activent TSME avec les anciens firmwares
    • avec AGESA 1.2.7.0, il est indiqué « not supported »
    • les CPU en version Pro prennent en charge TSME indépendamment du firmware ou de la carte mère
  • Le flag AGESA interne qui contrôle l’activation de TSME au démarrage renvoyait FALSE sur les puces grand public indépendamment du réglage du BIOS, et renvoyait TRUE sur les processeurs Pro lorsque la fonction était activée

La position d’AMD et les questions en suspens

  • La seule réaction officielle d’AMD est une réponse par e-mail affirmant que TSME est une « fonctionnalité de sécurité faisant partie d’AMD PRO Technologies et qui ne s’applique qu’aux CPU PRO »
  • Cette réponse marque la première limitation exprimée publiquement après des années pendant lesquelles la fonction a marché sur des puces grand public
  • On ignore si la disparition de TSME vient d’une décision politique délibérée d’AMD de réserver la fonction aux puces Pro, ou d’une régression involontaire apparue dans AGESA 1.2.7.0
  • Kilpatrick a retransmis les résultats des tests MSI aux ingénieurs AMD, puis a relancé la discussion six semaines plus tard
  • Selon Kilpatrick, l’équipe marketing produits de MSI a reçu directement d’AMD l’information selon laquelle TSME est réservé exclusivement aux processeurs de la série Pro
  • Lorsqu’on lui a demandé si le flag à FALSE sur les puces grand public venait d’une limitation au niveau du silicium ou d’une décision de politique firmware, Limonciello a répondu qu’il n’avait rien de plus à partager sur ce sujet

Différence entre TSME et SME

  • Rien n’indique clairement qu’AMD ait fait la promotion de TSME comme d’une fonction des Ryzen grand public
  • AMD indique depuis longtemps que la fonction de protection mémoire associée, Secure Memory Encryption (SME), n’est proposée que sur les gammes de CPU Pro et EPYC
  • SME est géré par l’OS, utilise une clé unique et permet à l’OS de chiffrer sélectivement des pages mémoire individuelles
  • TSME est géré par le firmware et chiffre toute la RAM sans intervention de l’OS
  • Lorsqu’on active TSME dans le BIOS, la fonction opère sans réglage spécifique de l’OS et bloque des attaques physiques comme les cold-boot exploits, l’espionnage de l’interface DRAM et le retrait de modules mémoire

Impact pour les utilisateurs

  • La suppression de la fonction est difficile à détecter sur les systèmes Windows, et demande aussi un travail technique conséquent pour être vérifiée sous Linux
  • Pour la plupart des utilisateurs de Ryzen grand public, l’impact concret reste limité
  • TSME sert à empêcher des scénarios où quelqu’un obtient un accès physique à la machine ou au matériel mémoire pour extraire directement des secrets depuis la RAM
  • TSME est plus important dans des contextes où l’on transporte un laptop sensible, traite des travaux confidentiels, dépend du chiffrement complet du disque, ou évolue dans des environnements où la saisie, le vol ou la modification matérielle sont des risques réalistes
  • Tant qu’AMD n’aura pas clarifié la situation ou rétabli la prise en charge, les utilisateurs qui ont réellement besoin du chiffrement mémoire sur du matériel AMD devront se tourner vers des systèmes Ryzen Pro ou EPYC

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News
  • Cette fonctionnalité n’a jamais été mise en avant comme un argument marketing sur les CPU grand public, et si quelqu’un de malveillant a un accès physique à mon matériel grand public, congeler la RAM à très basse température pour en lire les octets n’est pas très haut dans ma liste d’inquiétudes

    • Ce n’est pas utile seulement contre des attaques cryogéniques, ça aide aussi à se défendre contre row-hammer ou des problèmes liés au rafraîchissement de la DRAM
      À cause du scrambling, le noyau hôte ou les applications ne peuvent pas connaître la vraie disposition physique des bits dans la puce, ce qui rend plus difficile l’identification du layout nécessaire pour inverser certains bits. Ça reste peut-être possible, mais c’est une couche de défense supplémentaire contre les problèmes de sécurité liés à la mémoire
    • Ça me rappelle l’épisode de Seinfeld où George essaie de déplacer la borne d’arcade Frogger sans l’éteindre pour ne pas perdre son meilleur score
      https://youtu.be/5etwHVarNgI?t=256
    • J’ai pas mal de fonctionnalités sur les produits que j’achète qui ne sont pas non plus « marketées », et si elles disparaissent soudainement, ça me met quand même en colère
    • En regardant d’anciens journaux de modifications de l’ABL, cette décision de politique produit, à savoir prise en charge des seuls SKU PRO, semble avoir été implémentée dans le firmware depuis le départ
      https://github.com/amd/firmware_binaries/blob/main/cezanne/P...
      À mes yeux, ça ressemble plutôt à une fonctionnalité qui n’aurait jamais dû être activée sur ces pièces grand public dès le début
    • Il fallait quand même une communication transparente. En face, ce ne sont pas seulement des avocats mais aussi des clients, et la question n’est pas seulement de savoir si l’entreprise peut s’en sortir juridiquement
  • Le billet publié hier : « Users cry foul after AMD stripped memory crypto from its consumer CPUs », https://arstechnica.com/security/2026/06/users-cry-foul-afte...
    (https://news.ycombinator.com/item?id=48559827)

  • C’est assez étrange qu’il existe tout un ensemble de fonctionnalités que les entreprises limitent artificiellement pour l’utilisateur moyen, sans vraie raison, juste pour gonfler les prix. La virtualisation GPU en est un autre exemple
    La logique de segmentation du marché ne tient pas très bien non plus. Les entreprises paient énormément pour seulement quelques fonctionnalités exclusives comme celles-là

    • Ça me fait penser aux sièges chauffants par abonnement de BMW. Le hardware est déjà là, on a déjà payé des dizaines de milliers de dollars pour la voiture, mais on ne peut pas l’utiliser sans créer un revenu supplémentaire pour le constructeur
    • Une certaine version de ce concept ne me dérange pas. La fonctionnalité est techniquement présente sur tous les SKU, mais il faut l’acheter pour la déverrouiller
      Je déteste vraiment les abonnements. Il peut y avoir des exceptions pour des fonctionnalités qui entraînent un coût continu, mais pour un déverrouillage unique, ça ne devrait pas être un abonnement. En revanche, intégrer la fonctionnalité dans toutes les versions et la déverrouiller à l’achat peut, dans certaines conditions, être avantageux pour les consommateurs, et peut même permettre de baisser le prix du produit
      Ceux qui veulent payer y gagnent, ceux qui ne veulent pas payer tout de suite gardent l’option de changer d’avis plus tard pour une petite somme, et l’entreprise peut aussi générer un peu plus de profit
      Mais il faut des conditions. Pas d’abonnement pour un déverrouillage unique, et le fait pour le client de découvrir lui-même comment le déverrouiller sans achat devrait être légal et protégé
      Le cas où la fonctionnalité existe mais n’est proposée au déverrouillage à aucun prix mérite davantage de réflexion, mais selon moi le fait pour le client de l’activer lui-même devrait être fortement protégé par la loi
    • Il me semble qu’Intel avait essayé d’apporter la virtualisation GPU aux produits grand public, mais je ne sais pas trop ce qu’il est advenu de cette initiative
  • J’activais cette fonctionnalité parce qu’elle protège contre RAMbleed et les erreurs ECC, donc ce n’est pas limité aux seules attaques physiques

    • Tu es sûr ? Je pensais que ce n’était que de l’AES sans authentification
  • Je ne sais pas comment ça fonctionne, mais est-ce que cela signifie que si quelqu’un obtient un accès physique à un ordinateur allumé mais verrouillé, il peut accéder à l’intégralité du disque chiffré et à tout ce qui y est stocké ?
    Je pars de l’idée que la clé de déchiffrement saisie au démarrage reste en mémoire pendant toute la session de boot
    Si c’est exact, c’est assez surprenant. Cela voudrait dire que si quelqu’un s’introduit chez toi pendant que l’ordinateur est allumé et verrouillé, il peut contourner toute forme de chiffrement du disque. On peut tout à fait vouloir du chiffrement de disque même sur du matériel grand public

    • L’accès physique à un ordinateur est presque toujours le moyen le plus rapide et le plus simple de le compromettre. Et BitLocker sur Windows comme dm-crypt sur Linux chiffrent les données au repos
      Ce ne sont pas des mécanismes censés garantir la sécurité une fois la machine démarrée. Quand elle est en cours d’exécution, ce sont le MAC et les mots de passe utilisateur qui constituent les défenses appropriées
    • Avec de l’azote liquide et un disque de démarrage pour dump mémoire, ou bien un équipement pour intercepter le bus mémoire, oui c’est possible
    • Sur toutes les cartes mères que j’ai vues, cette fonctionnalité était désactivée par défaut
      D’après mon expérience, elle causait beaucoup de problèmes de stabilité avec VFIO, les pilotes NVIDIA, amdgpu, etc.
      L’attaque elle-même est aussi très sophistiquée. La plupart des gens n’ont pratiquement aucune raison de se soucier d’une coûteuse attaque cryogénique, et une agence à trois lettres obtiendra plutôt la clé avec une clé à molette
      Ça ne veut pas dire que ce changement est acceptable. Ça érode encore davantage une confiance déjà abîmée, mais il est extrêmement peu probable que l’utilisateur moyen soit directement affecté
      Il existe bien des moyens moins chers et plus simples d’obtenir les clés
  • Si cela peut être retiré discrètement, était-ce vraiment une fonction de sécurité ?
    Je déteste que des entreprises paient des ingénieurs pour empirer volontairement un produit à des fins de segmentation du marché, mais en dehors du datacenter cette fonctionnalité ne me semble pas si importante. Si une evil maid obtient l’accès au hardware, elle ne va pas plutôt attaquer l’USB ou le PCI que la RAM ?

    • Retirer furtivement une fonctionnalité dans une révision du firmware est inacceptable, qu’elle soit de sécurité ou non
    • Pour la retirer, il fallait la clé de signature du code firmware d’AMD. Si un attaquant possède cela et a du temps, il peut faire bien pire
  • Si je me souviens bien, AMD n’a jamais mis cette fonctionnalité en avant pour ces CPU, et elle n’était pas stable non plus
    La seule vraie erreur potentielle d’AMD, c’est de ne pas avoir été transparent sur la raison de la désactivation

  • Honnêtement, cette fonctionnalité n’a jamais vraiment bien marché. Il y avait surtout beaucoup de gels et autres problèmes avec VFIO, les pilotes NVIDIA et amdgpu

  • C’est ce genre de manœuvres qui montre l’importance de la concurrence sur le marché des CPU

    • C’est justement pour ça que la concurrence n’est pas autorisée sur le marché des CPU
      On pourrait tous fabriquer chez nous de petits circuits intégrés de classe 300 nm pour le prix d’un graveur Blu-ray et d’un peu de matériel de chambre noire. Les limites du silicium viennent moins d’un manque de hardware que d’un manque de liberté
    • Je trouve qu’on vit justement une époque où il y a énormément de choix en matière de CPU
  • Si cela faisait baisser le prix du CPU, même un peu, ce serait acceptable, mais on sait bien que ce ne sera pas le cas
    On entend maintenant dire que les soi-disant entreprises d’IA vont elles aussi commencer à consommer davantage de CPU à cause des « agents personnels de type agent », et j’espère que les particuliers ne seront pas exclus du marché des CPU pour cette raison