MDS - Microarchitectural Data Sampling - CVE-2018-12130, CVE-2018-12126, CVE-2018-12127, et CVE-2019-11091
Mis à jour
Récapitulatif
Quatre vulnérabilités ont été découvertes au niveau des processeurs, dont une catégorisée Importante par Red Hat Product Security. Si ces failles sont exploitées par un attaquant ayant un accès local au shell d'un système, les données du cache du CPU peuvent être exposées à des processus non autorisés. Un attaquant expérimenté pourrait utiliser ces failles pour lire la mémoire d'une instance virtuelle ou conteneurisée, ou du système hôte sous-jacent. Red Hat a préparé des mesures d'atténuation et a décrit en détails les mesures que les clients doivent prendre lorsqu'ils évaluent leur risque d'exposition et formulent leur réponse.
Contexte et détails du problème
Red Hat a été informé d'une série de problèmes d'implémentation microarchitecturale (hardware) qui pourraient permettre à un attaquant local non privilégié de contourner les restrictions de sécurité de mémoire classiques afin d'accéder en lecture à une mémoire privilégiée, normalement inaccessible. Ces failles peuvent également être exploitées par des codes malveillants s'exécutant à l'intérieur d'un conteneur. Ces problèmes affectent de nombreux microprocesseurs Intel modernes, nécessitant des mises à jour du noyau Linux, de la pile de virtualisation et du microcode du CPU. Les vulnérabilités ont été assignées CVE-2018-12130, avec un niveau d'impact catégorisé Important; CVE-2018-12126, CVE-2018-12127, et CVE-2019-11091 sont considérés comme ayant un niveau d'impact Modéré.
À l'heure actuelle, ces failles spécifiques sont connues d'affecter les processeurs basés Intel, bien que Red Hat Product Security s'attende à ce que les chercheurs continuent à sonder les vulnérabilités SMT (Multi-Threading Simultané) non liées, sur une gamme importante de fournisseurs.
Des failles ont été trouvées dans la manière dont les designs des microprocesseurs Intel mettent en jeu plusieurs micro-optimisations de performance. L'exploitation des vulnérabilités fournit aux attaquants un canal secondaire pour accéder aux données récemment utilisées sur le système appartenant à d'autres processus, conteneurs, machines virtuelles, ou au noyau.
Ces vulnérabilités sont appelées MDS (Microarchitectural Data Sampling) parce qu'elles reposent sur la spéculation pour obtenir l'état qui reste dans les structures internes du CPU.
CVE-2018-12126 - Microarchitectural Store Buffer Data Sampling ( MSBDS )
Une faille a été trouvée dans de nombreux designs de microprocesseur Intel en rapport à une fuite possible d'information de la structure de mémoire tampon de stockage de processeur qui contient les additions récentes (writes) à la mémoire.
Les microprocesseurs Intel modernes implémentent des micro-optimisations niveau hardware pour améliorer les performances d'écriture des données dans les caches des CPU. L'opération d'écriture (write) est divisée en sous-opérations STA (STore Address) et STD (STore Data). Ces sous-opérations permettent au processeur de transférer la logique de génération d'adresses dans ces sous-opérations pour des écritures optimisées. Ces deux sous-opérations écrivent dans une structure de processeur répartie et partagée qui s'appelle mémoire tampon de processeur ou "processor store buffer".
La mémoire tampon du processeur est conceptuellement un tableau d'adresses, de valeurs et d'entrées 'is valid'. Comme les sous-opérations peuvent s'exécuter indépendamment les unes des autres, elles peuvent chacune mettre à jour l'adresse et/ou les colonnes de valeurs de la table indépendamment. Cela signifie qu'à différents moments, l'adresse ou la valeur peut être non valide.
Le processeur est en mesure de transmettre spéculativement des entrées à partir de la mémoire tampon du stockage. Une telle division conceptuelle utilisée permet à ce type de transfert d'utiliser spéculativement des valeurs périmées, telles qu'une mauvaise adresse, et de renvoyer les données d'un ancien store sans lien de parenté. Comme cela ne se produit que pour les charges qui seront rééditées à la suite de la résolution de la panne ou après avoir reçu une assistance, le programme n'a pas eu d'impact architectural, mais l'état du tampon de stockage peut être divulgué à un code malveillant soigneusement conçu pour récupérer ces données via une analyse des canaux latéraux.
Les entrées de la mémoire tampon du processeur sont également réparties entre le nombre de Hyper-Threads actifs. Certaines conditions telles que le changement de power-state peuvent réaffecter les entrées de mémoire tampon du processeur dans un état de demi-mise à jour à un autre thread sans s'assurer que les entrées aient été effacées.
Ce phénomène est connu sous le nom de Fallout dans le milieu des chercheurs.
CVE-2018-12127 - Microarchitectural Load Port Data Sampling ( MLPDS )
Les microprocesseurs utilisent les 'load ports'' pour effectuer des opérations de chargement à partir de la mémoire ou de l'E/S. Pendant une opération de chargement, le port de chargement reçoit les données de la mémoire ou du sous-système d'E/S, puis les transmet aux registres de l'unité centrale et aux opérations dans les pipelines de l'unité centrale.
Dans certaines implémentations, le bus de données de reprise (writeback) de chaque port de charge peut conserver les valeurs d'anciennes opérations de charge jusqu'à ce que de nouvelles opérations de charge écrasent ces données.
MLPDS peut révéler des données de port de chargement périmées à des acteurs malveillants en cas de :
- charge défectueuse/d'assistance SSE/AVX/AVX-512 de plus de 64 bits
- charge défectueuse/d'assistance qui enjambe une limite de 64 octets est présente.
Dans les cas ci-dessus, l'opération de chargement fournit spéculativement des valeurs de données périmées provenant des structures de données internes aux opérations dépendantes. La transmission spéculative de ces données ne finit pas par modifier l'exécution du programme, mais elle peut être utilisée comme un widget pour déduire spéculativement le contenu de la valeur des données d'un processus victime par l'accès temporel au port de chargement.
CVE-2018-12130 - Microarchitectural Fill Buffer Data Sampling ( MFBDS )
C'est la question qui comporte le plus de risques, et Red Hat l'a jugée Importante. Une faille a été découverte par les chercheurs dans la mise en œuvre des tampons de remplissage utilisés par les microprocesseurs Intel.
Un tampon de remplissage contient les données qui n'ont pas pu être stockées dans le cache de données L1 du processeur, suite à une tentative d'utilisation d'une valeur qui n'est pas présente. Lorsqu'une erreur de cache de données de niveau 1 a lieu dans un noyau Intel, le design du tampon de remplissage permet au processeur de poursuivre d'autres opérations pendant que la valeur d'accès est chargée à un noveau plus élevés de cache. Le design permet également de transmettre le résultat à l'unité d'exécution, en acquérant la charge directement sans avoir à l'écrire dans le cache de données de niveau 1.
Une opération de chargement n'est pas découplée de la même manière qu'un store, mais elle implique une opération de génération d'adresse (AGU) (Address Generation Unit). Si l'AGU génère un défaut (#PF, etc.) ou une assistance (bits A/D), le design classique d'Intel bloque la charge et l'émet à nouveau plus tard. Avec les design actuels, cela permet (à la place) aux opérations de spéculation ultérieures de voir temporairement une valeur de données transférée à partir de la fente de mémoire tampon de remplissage avant que le chargement n'ait effectivement eu lieu. Il est ainsi possible de lire les données récemment accédées par l'intermédiaire d'un autre thread si l'entrée du tampon de remplissage n'est pas écrasée.
Ce phénomène est connu sous le nom de RIDL ou ZombieLoad dans le milieu des chercheurs.
CVE-2019-11091 - Microarchitectural Data Sampling Uncacheable Memory (MDSUM)
On a trouvé une faille dans l'implémentation du "tampon de remplissage", un mécanisme utilisé par les CPU modernes lorsqu'un cache-miss a lieu sur le cache du CPU L1. Si un attaquant peut générer une opération de chargement susceptible d'engendrer une erreur de page, l'exécution continuera spéculativement avec des données incorrectes à partir du tampon de remplissage, tandis que les données seront récupérées dans les caches de niveau supérieur. Ce temps de réponse peut être mesuré pour estimer les données dans le tampon de remplissage.
Remerciements
Red Hat remercie Intel et ses partenaires dans l'industrie pour avoir signalé ce problème et avoir collaboré aux mesures d'atténuation des risques.
De plus, Red Hat remercie les rapporteurs originaux:
>Microarchitectural Store Buffer Data Sampling (MSBDS) - CVE-2018-12126
Cette vulnérabilité a été détectée par des employés Intel (en interne). Intel tient à remercier Ke Sun, Henrique Kawakami, Kekai Hu et Rodrigo Branco. Elle a été signalée indépendamment par Lei Shi - Qihoo - 360 CERT et par Marina Minkin, Daniel Moghimi, Moritz Lipp, Michael Schwarz, Jo Van Bulck, Daniel Genkin, Daniel Gruss, Berk Sunar, Frank Piessens, Yuval Yarom (1University of Michigan, Worcester Polytechnic Institute, Graz University of Technology, imec-DistriNet, KU Leuven, University of Adelaide)
>Microarchitectural Load Port Data Sampling (MLPDS) - CVE-2018-12127
Cette vulnérabilité a été découverte en interne par les employés d'Intel et Microsoft. Intel tient à remercier Brandon Falk - Microsoft Windows Platform Security Team, Ke Sun, Henrique Kawakami, Kekai Hu, et Rodrigo Branco - Intel. Elle a été signalée indépendamment par Matt Miller - Microsoft, et par Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos et Cristiano Giuffrida - groupe VUSec à VU Amsterdam.
Microarchitectural Fill Buffer Data Sampling (MFBDS) - CVE-2018-12130
Cette vulnérabilité a été découverte en interne par les employés d'Intel. Intel tient à remercier Ke Sun, Henrique Kawakami, Kekai Hu et Rodrigo Branco. Elle a été rapportée indépendamment par Giorgi Maisuradze - Microsoft Research, et par Dan Horea Lutas, et Andrei Lutas - Bitdefender, et par Volodymyr Pikhur, et par Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos et Cristiano Giuffrida - groupe VUSec à VU Amsterdam et par Moritz Lipp, Michael Schwarz et Daniel Gruss - Graz University of Technology.
Microarchitectural Data Sampling Uncacheable Memory (MDSUM) - CVE-2019-11091
Cette vulnérabilité a été découverte en interne par les employés d'Intel. Intel tient à remercier Ke Sun, Henrique Kawakami, Kekai Hu et Rodrigo Branco. Elle a été trouvée indépendamment par Volodrmyr Pikhur, et par Moritz Lipp, Michael Schwarz, Daniel Gruss - Graz University of Technology, et par Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, et Cristiano Giuffrida - Groupe VUSec à VU Amsterdam.
Références supplémentaires
Pour plus d'informations sur ce genre de problèmes, consulter Intel’s Website
KCS: Simultaneous Multithreading in Red Hat Enterprise Linux
KCS: Disabling Hyper-Threading
KCS: CPU Side Channel Attack Index Page
KCS: Microcode availability for Pre-Haswell CPUs
KCS: Applying MDS CVE's patches on RHV hosts and manager node
KCS: RHOS Mitigation for MDS ("Microarchitectural Data Sampling") Security Flaws
Vidéo: All about MDS in about 3 minutes
Vidéo: Longform MDS Technical Explanation
Blog: Deeper Look at the MDS Vulnerability
Blog: Modern IT security: Sometimes caring is NOT sharing
Produits concernés
Red Hat Product Security a évalué l'impact de sécurité à un niveau Important.
Les versions de produits Red Hat suivants sont affectées :
Red Hat Enterprise Linux 5
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 8
Red Hat Atomic Host
Red Hat Enterprise MRG 2
Red Hat OpenShift Online v3
Red Hat Virtualization (RHV/RHV-H)
Red Hat OpenStack Platform
Bien que les conteneurs Linux de Red Hat ne soient pas directement touchés par les vulnérabilités hardware de tierce partie, leur sécurité dépend de l'intégrité de l'environnement du noyau de l'hôte. Red Hat recommande d'utiliser les versions les plus récentes de vos images de conteneurs. L'index de santé des conteneurs Container Health Index, qui fait partie du Catalogue des Conteneurs Red Hat, peut toujours être utilisé pour vérifier le statut de sécurité des conteneurs Red Hat. Pour protéger l'accès des conteneurs utilisés, vous devrez veiller à ce que l'hôte du conteneur (comme Red Hat Enterprise Linux ou Atomic Host) ait bien été mis à jour pour éviter la possibilité de ces attaques. Red Hat a créé une mise à jour d'Atomic Host pour ce cas d'utilisation.
Vecteur d'attaque | Vulnérable ? | Si vulnérable, comment ? | Mitigation |
---|---|---|---|
Processus utilisateur local contre hôte | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Processus utilisateur local contre un autre processus utilisateur | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Invité contre un autre invité | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Invité contre hôte | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Utilisateur hôte contre invité | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Conteneur contre hôte | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Conteneur contre autre conteneur | oui | mémoire protégée lecture | correctifs MDS noyau + microcode + désactiver HT |
Dans les systèmes multi-tenant où l'hôte a désactivé l'HT, les différents invités ne doivent pas avoir accès aux threads sur le même noyau et ne devraient pas être vulnérables. Le rendement de l'hôte et la disponibilité globale des ressources seront touchés.
Dans les systèmes multi-tenant où l'hôte a activé l'HT et où l'hyperviseur est vulnérable, les invités seront également vulnérables qu'ils aient désactivé l'HT ou non.
Dans les systèmes multi-tenant où l'hôte a activé l'HT et où l'hyperviseur n'est pas vulnérable, les invités devraient envisager de désactiver l'HT pour se protéger.
Diagnostiquer votre vulnérabilité
Utilisez le script de détection pour déterminer si votre système est actuellement vulnérable à ce défaut. Pour vérifier la légitimité du script, vous pouvez également télécharger la signature GPG détachée.
Pour les abonnés exécutant les produits Red Hat Virtualization, il existe un article de base de connaissance qui a été créé pour vérifier que le microcode/firmware fourni par OEM ait bien été appliqué.
Après avoir appliqué les mises à jour pertinentes, les utilisateurs peuvent vérifier que les correctifs sont en vigueur en exécutant l'une ou l'autre des options suivantes :
# dmesg | grep "MDS:"
[ 0.162571] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[ 181.862076] MDS: Mitigation: Clear CPU buffers
# cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable
Action
Nous conseillons à tous les clients de Red Hat exécutant des versions de produits Red Hat affectés de procéder aux mises à jour dès que les correctifs sont disponibles. On conseille aux clients d'appliquer les mises à jour qui conviennent immédiatement et d'activer les solutions qu'ils estiment appropriées.
L'ordre dans lequel les correctifs sont appliqués n'est pas important, mais après la mise à jour du firmware et des hyperviseurs, chaque système ou machine virtuelle devra être fermée, puis redémarrée pour pouvoir détecter le nouveau type de hardware.
Mises à jour pour les produits concernés
Produit | Package | Alerte / Mise à jour |
Red Hat Enterprise Linux 8 (z-stream) | noyau | RHSA-2019:1167 |
Red Hat Enterprise Linux 8 | kernel-rt | RHSA-2019:1174 |
Red Hat Enterprise Linux 8 | virt:rhel | RHSA-2019:1175 |
Red Hat Enterprise Linux 8 | microcode_ctl | RHEA-2019:1211 |
Red Hat Enterprise Linux 7 (z-stream) | noyau | RHSA-2019:1168 |
Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2019:1176 |
Red Hat Enterprise Linux 7 | qemu-kvm | RHSA-2019:1178 |
Red Hat Enterprise Linux 7 | qemu-kvm-rhev | RHSA-2019:1179 |
Red Hat Enterprise Linux 7 | libvirt | RHSA-2019:1177 |
Red Hat Enterprise Linux 7 | microcode_ctl | RHEA-2019:1210 |
Red Hat Enterprise Linux 7.5 Extended Update Support [1] | noyau | RHSA-2019:1155 |
Red Hat Enterprise Linux 7.5 Extended Update Support [1] | qemu-kvm | RHSA-2019:1183 |
Red Hat Enterprise Linux 7.5 Extended Update Support [1] | libvirt | RHSA-2019:1182 |
Red Hat Enterprise Linux 7.5 Extended Update Support [1] | microcode_ctl | RHEA-2019:1213 |
Red Hat Enterprise Linux 7.4 Extended Update Support [1] | noyau | RHSA-2019:1170 |
Red Hat Enterprise Linux 7.4 Extended Update Support [1] | qemu-kvm | RHSA-2019:1185 |
Red Hat Enterprise Linux 7.4 Extended Update Support [1] | libvirt | RHSA-2019:1184 |
Red Hat Enterprise Linux 7.4 Extended Update Support [1] | microcode_ctl | RHEA-2019:1214 |
Red Hat Enterprise Linux 7.3 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | noyau | RHSA-2019:1171 |
Red Hat Enterprise Linux 7.3 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | qemu-kvm | RHSA-2019:1189 |
Red Hat Enterprise Linux 7.3 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | libvirt | RHSA-2019:1187 |
Red Hat Enterprise Linux 7.3 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | microcode_ctl | RHEA-2019:1215 |
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | noyau | RHSA-2019:1172 |
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | qemu-kvm | RHSA-2019:1188 |
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | libvirt | RHSA-2019:1186 |
Red Hat Enterprise Linux 7.2 Services de mise à jour de SAP Solutions, & Support Mise à jour Avancé [2], [3] | microcode_ctl | RHEA-2019:1216 |
Red Hat Enterprise Linux 6 (z-stream) | noyau | RHSA-2019:1169 |
Red Hat Enterprise Linux 6 | qemu-kvm | RHSA-2019:1181 |
Red Hat Enterprise Linux 6 | libvirt | RHSA-2019:1180 |
Red Hat Enterprise Linux 6 | microcode_ctl | RHEA-2019:1212 |
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé [2] | noyau | RHSA-2019:1193 |
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé [2] | qemu-kvm | RHSA-2019:1195 |
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé [2] | libvirt | RHSA-2019:1194 |
Red Hat Enterprise Linux 6.6 Support Mise à jour Avancé [2] | microcode_ctl | RHEA-2019:1218 |
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé [2] | noyau | RHSA-2019:1196 |
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé [2] | qemu-kvm | RHSA-2019:1198 |
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé [2] | libvirt | RHSA-2019:1197 |
Red Hat Enterprise Linux 6.5 Support Mise à jour Avancé [2] | microcode_ctl | RHEA-2019:1219 |
Red Hat Enterprise Linux 5 Support Mise à jour Prolongé [5] | noyau | voir ci-dessous |
RHEL Atomic Host [4] | noyau | respin en attente |
Red Hat Enterprise MRG 2 | kernel-rt | RHSA-2019:1190 |
Red Hat Virtualization 4 | vdsm | RHSA-2019:1203 |
Red Hat Virtualization 4.2 | vdsm | RHSA-2019:1204 |
Red Hat Virtualization 4.3 | rhvm-setup-plugins | RHSA-2019:1205 |
Red Hat Virtualization 4.2 | rhvm-setup-plugins | RHSA-2019:1206 |
Red Hat Virtualization 4 | hôte de virtualisation | RHSA-2019:1207 |
Red Hat Virtualization 4 | rhvm-appliance | RHSA-2019:1208 |
Red Hat Virtualization 4.2 | hôte de virtualisation | RHSA-2019:1209 |
Red Hat OpenStack Platform 14 (Rocky) | qemu-kvm-rhev | RHSA-2019:1202 |
Red Hat OpenStack Platform 14 (Rocky) | Image du conteneur | RHBA-2019:1242 |
Red Hat OpenStack Platform 13 (Queens) | qemu-kvm-rhev | RHSA-2019:1201 |
Red Hat OpenStack Platform 13 (Queens) | Image du conteneur | RHBA-2019:1241 |
Red Hat OpenStack Platform 10 (Newton) | qemu-kvm-rhev | RHSA-2019:1200 |
Red Hat OpenStack Platform 9 (Mitaka) | qemu-kvm-rhev | RHSA-2019:1199 |
[1] Un abonnement EUS actif est requis pour accéder à ce correctif. Veuillez contacter l'équipe de ventes de Red Hat ou votre représentant commercial personnel pour plus d'informations si votre compte n'a pas d'abonnement EUS actif en cours.
[2] Un abonnement AUS actif est exigé pour pouvoir accéder à ce correctif dans RHEL AUS.
Qu'est-ce qu'un abonnement AUS (Advanced Update Support) pour missions critiques ?
[3] Un add-on Update Services for SAP Solutions actif ou un abonnement TUS est requis pour accéder à ce correctif dans RHEL E4S / TUS.
[4] Pour plus d'informations sur la façon de mettre à jour Red Hat Enterprise Atomic Host, veuillez consulter Deploying a specific version fo Red Hat Enterprise Atomic Host.
FAQ: Red Hat Enterprise Linux 5 Extended Life Cycle Support (ELS) Add-On
[5] À l'heure actuelle, compte tenu de la gravité de ces problèmes, où Red Hat Enterprise Linux 5 est dans son cycle de vie de support, et du faible nombre de types de CPU qui disposeront du microcode nécessaire pour ces mesures de mitigation, RHEL5 ne sera pas pris en compte. Veuillez contacter le support Red Hat pour connaître les chemins et options de mise à niveau disponibles.
NOTE : Les abonnés peuvent contacter leur fournisseurs de matériel OEM afin d'obtenir les versions de microcode / firmware de CPU les plus récents.
Mitigation
Il n'y a pas de solution connue d'atténuation des risques totale, sinon que d'appliquer les mises à jour logiciel des fournisseurs, combinées au firmware / microcode CPU des OEM. Tous les clients de Red Hat doivent appliquer les solutions proposées par leur fournisseur pour corriger leurs CPU, et mettre à jour le noyau dès que les correctifs sont disponibles. Veuillez consulter votre fournisseur OEM ou le fabricant de CPU de votre système pour plus de détails sur la disponibilité du microcode pour les plates-formes prises en charge.
Désactiver le SMT pour les systèmes affectés réduira une partie de la surface d'attaque, mais n'éliminera pas complètement toutes les menaces liées à ces vulnérabilités. Pour atténuer les risques que présentent ces vulnérabilités, les systèmes auront besoin d'une mise à jour du microcode, d'une mise à jour du noyau, de correctifs de virtualisation et les administrateurs devront évaluer si la désactivation du SMT/HT est le bon choix pour leur déploiement. De plus, les applications peuvent avoir un impact sur les performances. Voir l'article Disabling Hyper-Threading pour plus d'informations sur la désactivation du SMT.
On conseille à nos clients de prendre une approche basée risque pour résoudre ce problème. Les systèmes qui exigent des niveaux de sécurité et de confiance élevés doivent être réglés en premier, et doivent être isolés des systèmes suspects jusqu'à ce qu'ils puissent être traités afin de réduire le risque d'exploitation.
Playbook Ansible
De plus, un playbook Ansible, disable_mds_smt_smt_mitigate.yml, est fourni ci-dessous. Ce playbook désactivera SMT sur le système en cours d'exécution, désactivera SMT pour les redémarrages à venir du système, et appliquera les mises à jour associées. Pour utiliser le playbook, spécifiez les hôtes sur lesquels vous souhaitez désactiver SMT avec le var supplémentaire HOSTS :
ansible-playbook -e HOSTS=web,mail,ldap04 disable_mds_smt_mitigate.yml
Le playbook peut également ajouter des arguments de ligne de commande pour empêcher la ré-activation du SMT en réglant la variable FORCEOFF sur true :
ansible-playbook -e HOSTS=hypervisors -e FORCEOFF=true disable_mds_smt_mitigate.yml
Pour vérifier la légitimité du playbook, vous pouvez télécharger la signature GPG détachée.
Impact sur la performance et désactiver MDS
Les mesures d'atténuation de MDS CVE se sont révélées avoir une incidence sur la performance. L'impact se fera davantage sentir dans les applications où le taux de transition utilisateur-kernel-utilisateur est élevé. Par exemple, les appels système, les NMI et les interruptions.
Bien qu'il n'y ait aucun moyen de dire quel sera l'impact par rapport à une charge de travail donnée, nous avons mesuré l'impact dans nos tests :
- Les applications qui passent beaucoup de temps en mode utilisateur avaient tendance à afficher le plus faible ralentissement de performance, habituellement de l'ordre de 0 à 5 %.
- Les applications qui faisaient beaucoup d'E/S de petits blocs ou de petits réseaux de paquets ont démontré des ralentissements de performance de l'ordre de 10 à 25 %.
- Certains micro-repères qui n'ont rien fait d'autre que d'entrer et de revenir de l'espace utilisateur à l'espace du noyau ont démontré des ralentissements de performance plus importants.
L'impact de la solution de mitigation MDS sur les performances peut être mesuré en exécutant votre application avec MDS activé puis désactivé. La mitigation MDS est activée par défaut. La mitigation MDS peut être entièrement activée, avec SMT également désactivé en ajoutant l'option "mds=full,nosmt" à la ligne de commande de démarrage du noyau. La mitigation MDS peut être complètement désactivée en ajoutant l'option "mds=off" à la ligne de commande de démarrage du noyau. Il n'y a aucun moyen de la désactiver à l'exécution.
Pour l'impact de performance de la désactivation de l'hyperhreading, consulter la section “Disabling Hyper-Threading” à l'adresse suivante : https://access.redhat.com/security/vulnerabilities/L1TF-perf
Comments