La mention de Spectre et Meltdown suffit à envoyer des frissons dans n’importe quelle colonne vertébrale d’InfoSec. Un certain nombre de ces lots de vulnérabilités de sécurité traitent de l’exécution spéculative et de la manière dont un processeur peut divulguer des données tout en exécutant du code de manière spéculative. Cette semaine, AMD a anticipé l’espace de sécurité en détaillant un problème de sécurité potentiel concernant sa nouvelle fonctionnalité Predictive Store Forwarding basée sur Zen 3, conçue pour améliorer les performances du code en prédisant les dépendances entre les charges et les magasins. AMD souligne clairement que la plupart des utilisateurs n’auront pas besoin de prendre de mesures, car le risque pour une utilisation générale par les consommateurs de toute violation est faible et aucun code connu n’est vulnérable.

Les prédictions créent des prédilections pour les données

Les processeurs modernes utilisent un certain nombre de techniques intelligentes pour améliorer les performances. Un certain nombre de ces techniques relèvent de la rubrique «  spéculation  » – à un niveau élevé, lorsqu’un processeur exécute du code comme une simple branche vrai / faux, plutôt que d’attendre que le résultat de cette vérification vrai / faux vienne de la mémoire, il commencera à exécuter les deux branches à la fois. Lorsque le résultat vrai / faux revient de mémoire, la branche qui avait la bonne réponse est conservée et l’autre est détruite. Les processeurs modernes prédisent également les adresses mémoire dans des boucles répétitives, ou des valeurs dans une séquence, en apprenant quel code a déjà été traité. Par exemple, si votre boucle incrémente une adresse de chargement de 1024 octets à chaque cycle, de 100e boucle, le processeur a appris d’où il s’attend à ce que la prochaine charge provienne. Tout cela est plutôt intelligent et permet de nombreuses performances.

L’inconvénient de ces techniques, mis à part la consommation d’énergie supplémentaire nécessaire pour exécuter plusieurs branches, est le fait que les données circulent à la fois à partir de la branche correcte et de la branche incorrecte. Cette branche incorrecte peut accéder à des données qu’elle ne devrait pas être censée être et les stocker dans des caches, où elles peuvent être lues ou accessibles par différents threads. Un attaquant malveillant pourrait amener la branche incorrecte à accéder aux données auxquelles elle ne devrait pas accéder. Le concept comporte de nombreuses couches et est beaucoup plus compliqué que ce que j’ai présenté ici, mais dans tous les cas, la spéculation pour des raisons de performances sans considération pour la sécurité peut conduire à des données rapides mais fuyantes.

Pour la plupart, l’ensemble du secteur, y compris AMD, Intel et Arm, a été sensible à ce type d’attaques par canal latéral. Alors que les attaques de style Meltdown sont plus isolées des microarchitectures Intel, les attaques de type Spectre sont à l’échelle de l’industrie et ont le potentiel de fuir la mémoire utilisateur même dans des scénarios de type navigateur.

Transfert de magasin prédictif

Le document d’AMD de cette semaine est une analyse de sécurité de sa nouvelle fonctionnalité PSF (Predictive Store Forwarding) dans Zen 3. PSF identifie les modèles d’exécution et les points communs dans le code de stockage / chargement répété, connu sous le nom de transfert de stockage à chargement. PSF permet au thread de spéculer sur le prochain résultat store-to-load avant d’attendre de voir si ce résultat est même nécessaire en premier lieu. Si le résultat est finalement nécessaire, nous n’avons pas besoin d’attendre, et la prédiction / spéculation a fait son travail et a permis des performances supplémentaires.

AMD a identifié que sa fonction PSF pourrait être vulnérable de deux manières.

Premièrement, le modèle de transfert de stockage à chargement peut changer de manière inattendue. Si la paire stockage / chargement est basée sur un modèle de dépendance fixe (tel qu’une longueur de pas de données fixe à l’aide d’un multiplicateur externe), la fonction PSF apprend ce modèle et continue. Si cette dépendance change soudainement ou devient effectivement aléatoire, la fonction PSF continuera à spéculer jusqu’à ce qu’elle ait appris le nouveau modèle de dépendance. Comme il continue de spéculer pendant ce temps, il a le potentiel d’attirer des données inutiles dans les caches qui peuvent être sondées par des threads externes, ou le temps d’accès à ces données sensibles changera pour les threads externes, et cela peut être surveillé.

Deuxièmement, PSF peut être vulnérable par l’alignement / l’aliasing de la mémoire des prédictions avec des dépendances. Le PSF est conçu pour fonctionner et suivre les données sur la base d’une partie de l’alignement d’adresse mémoire. Par conséquent, lorsque la spéculation entre stockage et chargement se produit avec un alignement, si une dépendance est dans le mélange de cette spéculation et que la dépendance finit par ne pas aligner les valeurs prédites, cela peut entraîner une spéculation incorrecte. Les données sont toujours valables pour une spéculation qui ne sera pas utilisée, mais c’est là que réside le problème: les données peuvent être sensibles ou en dehors des limites de la mémoire du thread en question.

Limites

PSF se produit uniquement dans un thread singulier – la façon dont PSF apprend où la prochaine paire de stockage / chargement doit être est individuelle pour chaque thread. Cela signifie qu’une attaque de cette nature repose sur le code sous-jacent qui fait que la spéculation PSF s’aventure dans la mémoire involontaire, et ne peut pas être exploitée directement par un thread entrant, même sur le même cœur. Cela peut sembler quelque peu inattaquable, mais si vous avez déjà utilisé un simulateur de code dans un navigateur Web, votre code s’exécute dans le même thread que le navigateur.

La formation PSF est également limitée par le contexte – un certain nombre de valeurs liées aux threads (CPL, ASID, PCID, CR3, SMM) définissent le contexte et si l’une de ces un nouveau contexte efficace a été créé. La commutation de contexte se produit également avec les appels système, vidant également les données.

AMD répertorie que pour exploiter PSF, il nécessite que les paires stockage-chargement soient proches les unes des autres dans le code d’instruction. De plus, le PSF est entraîné par des prédictions successives de branchement correctes – une fausse prédiction complète peut provoquer un vidage de pipeline entre le magasin et la charge, supprimant toutes les données potentiellement nuisibles.

Effet sur les consommateurs, les utilisateurs et l’entreprise

AMD (et ses partenaires de sécurité) a identifié que l’impact de l’exploitation PSF est similaire à celui du contournement de magasin spéculatif (Spectre v4), et un problème de sécurité survient lorsque le code implémente un contrôle de sécurité qui peut être contourné. Cela peut se produire si un programme héberge du code non approuvé qui peut influencer la façon dont d’autres codes spéculent – AMD cite qu’un navigateur Web pourrait livrer une telle attaque, similaire à d’autres vulnérabilités de type Spectre.

En dépit d’être similaire à d’autres attaques Spectre, l’analyse de sécurité d’AMD indique qu’un attaquant devrait effectivement entraîner le PSF d’un thread avec un code malveillant dans le même contexte de thread. Ceci est quelque peu difficile à faire en mode natif, mais peut être causé par des accès de sécurité élevés. Cela étant dit, la PSF ne se produit pas dans des espaces d’adressage séparés activés par les mécanismes matériels actuels, tels que la virtualisation cryptée sécurisée. Les données PSF sont vidées si un accès aux données non valide se produit.

Pour le marché des entreprises, AMD affirme que le risque de sécurité est atténué grâce à l’isolation de l’espace d’adressage basée sur le matériel. Si une entité ne dispose pas d’un moyen d’isoler l’espace d’adressage dans son déploiement, la PSF peut être désactivée en définissant MSR 48h bit 2 ou MSR 48h bit 7 sur 1. Les seuls produits qui seraient affectés à partir d’aujourd’hui sont les processeurs Ryzen 5000 et Processeurs EPYC Milan 7003.

AMD n’a actuellement connaissance d’aucun code à l’état sauvage qui pourrait être vulnérable à ce type d’attaque. Le risque de sécurité est considéré comme faible et AMD recommande que la plupart des utilisateurs finaux ne voient aucun risque de sécurité en laissant la fonctionnalité activée, qui sera toujours la valeur par défaut à l’avenir.

Le document complet d’analyse de la sécurité, ainsi qu’une suggestion d’atténuation pour l’entreprise, sont disponibles sur ce lien.