Attaque noyau « side-channel » par L1 Terminal Fault - CVE-2018-3620 & CVE-2018-3646

Produits concernés

Red Hat Product Security a évalué l'impact de sécurité de CVE-2018-3620 & CVE-2018-3646 au niveau Important.

Les versions de produits Red Hat suivants sont concernées :

• Red Hat Enterprise Linux 5

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Atomic Host

• Red Hat Enterprise MRG 2

• Red Hat OpenShift Online v3

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7

• Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7

• Red Hat OpenStack Platform 8.0 (Liberty)

• Red Hat OpenStack Platform 8.0 (Liberty) director

• Red Hat OpenStack Platform 9.0 (Mitaka)

• Red Hat OpenStack Platform 9.0 (Mitaka) director

• Red Hat OpenStack Platform 10.0 (Newton)

• Red Hat OpenStack Platform 11.0 (Ocata)

• Red Hat OpenStack Platform 12.0 (Pike)

• Red Hat OpenStack Platform 13.0 (Queens)

• Red Hat Virtualization (RHEV-H/RHV-H)

Bien que les conteneurs Linux de Red Hat ne soient pas directement affectés par les problèmes du noyau, leur sécurité dépend de l'intégrité de l'environnement du noyau hôte. Red Hat vous recommande d'utiliser les versions les plus récentes de vos images de conteneurs. Le Container Health Index, qui fait partie du catalogue de conteneurs de Red Hat (Red Hat Container Catalog ), peut toujours être utilisé pour vérifier l'état de sécurité des conteneurs Red Hat. Pour protéger la confidentialité des conteneurs utilisés, vous devrez vous assurer que l'hôte du conteneur (comme Red Hat Enterprise Linux ou Atomic Host) a été mis à jour contre ces attaques. Red Hat a publié une mise à jour d'Atomic Host pour ce cas d'utilisation.

Description et impact de l'attaque

Vecteur d'attaque d'hôte traditionnel :

Lorsqu'un processeur prend en charge l'exécution spéculative d'instructions, une charge spéculative d'adresse virtuelle qui ne peut pas être traduite en adresse physique entraîne une exception de faute de page pendant son processus de traduction. Avant que cette exception «page-fault » ne soit produite, l'exécution spéculative de l'instruction de chargement utilise l'adresse physique de l'entrée de la structure de pagination non présent (P flag = 0) OU sets de bits réservés pour accéder à la mémoire physique. Si l'emplacement de mémoire physique a été mis en cache dans le cache de données L1, la charge spéculative lit les données à partir d'un emplacement de mémoire physique inapproprié. Par conséquent, les opérations spéculatives ultérieures utilisent ces données et cela peut avoir un impact mesurable sur les caches qu'un attaquant peut utiliser pour lire des données non autorisées.

Un processus ou un utilisateur système non privilégié pourrait exploiter la vulnérabilité L1TF pour lire des données à partir d'emplacements de mémoire physique arbitraires du noyau et/ou d'autres processus s'exécutant sur le système, si les données sont d'abord chargées dans le cache de données L1. Comme les chargements dans le cache de données L1 sont un composant intrinsèque du processeur, un attaquant malveillant n'a qu'à attendre qu'un programme contenant des secrets intéresseants pour charger ces secrets tout en effectuant des opérations normales. Cela peut inclure des clés cryptographiques et d'autres données.

Vecteur d'attaque de virtualisation :

Les environnements d'invités virtualisés aggravent l'impact de l'exploitation de cette vulnérabilité. Dans les environnements virtualisés, les invités exécutent souvent un système d'exploitation qui gère la mémoire comme s'il s'agissait d'un système hôte bare metal (nu). Ce que le système d'exploitation invité perçoit comme mémoire physique est en réalité un espace d'adressage virtuel sur l'hôte, créé par le moniteur de machine virtuelle (VMM, par exemple KVM), également connu sous le nom d'hyperviseur. L'hyperviseur introduit une couche de virtualisation de la mémoire pour s'assurer qu'il a le contrôle de la véritable mémoire physique de l'hôte et qu'il peut fournir des espaces d'adresses virtuelles isolés à de nombreux invités tout en gérant leur accès à la mémoire physique de l'hôte. Cela signifie que les environnements virtualisés ont deux niveaux de traduction mémoire.

Afin de faciliter la traduction efficace des adresses physiques des invités en adresses physiques de l'hôte, les processeurs matériels ont mis en place la fonction Extended Page Table (EPT).

L'EPT est similaire aux structures hiérarchiques de pagination utilisées par le système d'exploitation hôte pour traduire les adresses virtuelles en adresses de mémoire physique. Lors de la traduction des adresses physiques des invités en adresses physiques de l'hôte, tout comme les exceptions «page-fault» sur l'hôte, les exceptions EPT Violation entraînent des sorties de VM, indiquant que la traduction de l'adresse physique de l'invité ne peut pas être résolue en adresse physique de l'hôte OU que l'invité n'a pas les permissions d'accéder à la mémoire de l'hôte donnée.

Comme pour l'hôte, l'exécution spéculative d'instructions par un utilisateur invité peut tirer parti de ces sorties de VM induites par les violations EPT pour lire les données de la mémoire physique de l'hôte par le biais d'attaques de cache «side-channel». Comme le système d'exploitation invité peut contrôler les bits d'adresse physique des invités dans l'entrée de pagination EPT, un utilisateur invité peut cibler des adresses physiques spécifiques de l'hôte et lire les données via le cache de données L1, y compris la mémoire arbitraire du noyau de l'hôte et/ou la mémoire des autres invités/processus s'exécutant sur l'hôte.

Vecteur d'attaque multithreading en simultané (SMT) :

Le multithreading simultané (SMT) permet aux processeurs modernes d'améliorer les performances du système en exécutant simultanément plus d'un flux d'instructions sur des processeurs logiques séparés. C'est-à-dire que le CPU crée deux ou plusieurs processeurs logiques avec leur propre jeu de registres de données, registres de contrôle, registres de segments, etc. qui forment leur état architectural. Ces processeurs logiques exécutent des flux d'instructions séparés tout en partageant le même moteur d'exécution, les caches de processeur, les TLB, l'interface de bus système, etc.

Si deux processeurs logiques se partagent le cache du processeur, une opération de manipulation du cache effectuée par un processeur logique sera visible pour l'autre. C'est-à-dire qu'une application/invité s'exécutant sur un processeur logique pourrait tirer parti de L1TF et de l'exécution spéculative d'instructions pour lire le contenu arbitraire de la mémoire d'autres processus et du noyau à partir du cache de données partagé.

La nature simultanée de l'Intel Hyper-threading fait que vider le cache sur un processeur logique pair lors d'un changement d'instances de machines virtuelles exécutant dessus laisse une petite fenêtre de temps pendant laquelle les secrets peuvent être rechargés par le pair et pendant laquelle les secrets sont visibles à un attaquant malveillant exécutant du code sur l'autre processeur logique. Il n'existe actuellement aucun moyen standard pour garantir que cela ne puisse pas se produire,

Par conséquent, les environnements virtualisés ne devraient pas programmer deux machines virtuelles différentes pour partager deux processeurs logiques à partir d'un seul noyau. En outre, lorsqu'une pile Linux complète s'exécute sur l'hôte, capable de charger ses propres secrets en réponse à des événements tels que des interruptions, il n'est pas prudent d'activer l'hyperthreading si on exécute des invités non fiables sur un processeur logique.

Impact sur la performance

Essayer de mitiger le risque L1TF dans des environnements bare metal (nus) qui n'utilisent pas la virtualisation a un impact négligeable sur les performances et ne nécessite pas d'action spécifique au-delà des mises à jour.

L'atténuation du risque L1TF dans les environnements virtualisés exige que l'hyperviseur vérifie s'il doit vider le cache de données L1 (L1D) des secrets potentiels d'autres machines virtuelles (ou de l'hôte) chaque fois qu'il commence à exécuter le code de la machine virtuelle. Selon la charge de travail, il peut également être nécessaire de désactiver l'Intel Hyper-threading, afin d'empêcher une machine virtuelle malveillante s'exécutant sur un hyperthread d'en attaquer une autre sur son thread pair.

Le cache de données L1 met les données à la disposition du processeur beaucoup plus rapidement que la mémoire principale et (presque) toutes les données chargées à partir de la mémoire doivent passer par lui. Une fois que le cache de données L1 est vidé, le CPU doit passer des centaines de cycles pour remplir à nouveau ces entrées à partir des caches de niveau inférieur. Cela coûte cher en termes de temps consacré à l'accès aux données. En termes d'efficacité relative, le cache de données L1 prend 1x cycles CPU, alors que le même accès aux données à partir de caches de niveau inférieur peut prendre 4x cycles CPU. L'accès aux données à partir de la mémoire principale peut prendre 60-70x ou plus de cycles. Comme les données contenues dans le cache de données L1 sont également contenues dans les caches de niveau supérieur, elles seront généralement rechargées à partir du cache L2 avec un impact modeste sur la performance. Cette surcharge augmente également la latence des interruptions externes et autres événements.

De même, l' Hyper-Threading (une implémentation SMT) exécute plus d'un flux d'instructions simultanément pour améliorer les performances du système. Désactiver ces threads réduirait de moitié le nombre de processeurs logiques vus par le système, réduisant ainsi de manière significative le débit de calcul global d'un système et sa performance.

Il est à noter que l'incidence réelle de ces mesures sur la performance dépend de la charge de travail et peut varier d'une charge de travail à l'autre. Pour obtenir des informations supplémentaires sur l'impact spécifique de la charge de travail sur la performance, consulter :  Performance considerations for L1 Terminal Fault

Diagnostiquer votre vulnérabilité

Utilisez le script de détection pour déterminer si votre système est actuellement vulnérable à cette vulnérabilité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également. La version actuelle du script est 1.2.

De plus, deux playbooks Ansible sont fournis ci-dessous. Le premier, CVE-2018-3620-fix_disable_ht.yml, peut être appliqué aux systèmes qui n'ont pas été mis à jour pour adresser L1TF et désactiver l'Hyper-Threading sans redémarrer le système. Le playbook fera un effort pour déterminer si le système agit en tant qu'hyperviseur et s'il a des VM en cours d'exécution, mais il faut savoir que la désactivation de l'Hyper-Threading (hors ligne) peut provoquer un comportement inattendu dans les applications avec une affinité cœur/thread spécifique. Si le noyau du système n'inclut pas les fonctionnalités nécessaires, il échouera avec un message à cet effet. Dans ce cas, il est recommandé de mettre à jour le dernier noyau et d'utiliser le deuxième playbook pour bénéficier des fonctionnalités d'un noyau compatibles avec L1TF.

Pour utiliser le playbook CVE-2018-3620-fix_disable_ht.yml, il vous suffit d'invoquer ansible-playbook avec les hôtes que vous souhaitez modifier dans HOSTS extra var:
ansible-playbook -e "HOSTS=webservers,db01,portal" CVE-2018-3620-fix_disable_ht.yml

Le deuxième playbook, CVE-2018-3620-apply_settings.yml, vous aidera à activer les mesures d'atténuation de risque provenant d'un noyau compatible avec L1TF. Il y a trois paramètres que vous pouvez spécifier :

• FLUSH=1 changera le comportement du noyau et du module du noyau kvm-intel pour vider le cache de données L1 à chaque entrée de VM, pas seulement quand le noyau détecte qu'un vidage est nécessaire. Bien qu'il y ait des implications en termes de performance, cela nous fournira une meilleure garantie que l'information n'est pas partagée entre les VM, et devrait empêcher les fuites d'information telles que la déréandomisation de l'ASLR. Ce réglage ne devrait être nécessaire que quand vous utilisez un hyperviseur avec des systèmes invités non fiables.
• SMT=1 désactivera l'Hyper-Threading, aussi bien pour le système live que pour le démarrage. Comme pour le premier playbook, on tente de déterminer s'il y a des invités actifs afin d'empêcher les discussions hors ligne possédant une affinité définie.
• FORCE=1 empêchera, lorsqu'il est combiné avec SMT=1, de réactiver le SMT au moment de l'exécution via l'interface /sys/devices/cpu/smt/control. Si FORCE n'est pas spécifié, les utilisateurs ayant suffisamment de permissions peuvent réactiver ou désactiver le SMT au moment de l'exécution.

De plus, le playbook fournit un argument RESET=1 qui supprimera les mesures d'atténuation du risque ci-dessus, et ramènera le système à son comportement par défaut de SMT activé et de vidages de cache de données L1 conditionnel dès l'arrivée d'une VM. Un redémarrage est nécessaire après RESET=1.

Pour utiliser CVE-2018-3620-apply_settings.yml, spécifiez les fonctionnalités que vous souhaitez définir dans les vars supplémentaires, ainsi que les systèmes que vous souhaitez cibler dans la variable HOSTS. Par exemple :

Pour désactiver le SMT, mais autoriser les changements en cours d'exécution, et conserver le comportement de vidage par défaut conditionel du cache de données L1 :
ansible-playbook -e "HOSTS=webservers SMT=1" CVE-2018-3620-apply_settings.yml>.

Pour appliquer toutes les mesures d'atténuation de risque et empêcher les changements en cours d'exécution :
ansible-playbook -e "HOSTS=vmserver01 FLUSH=1 SMT=1 FORCE=1" CVE-2018-3620-apply_settings.yml.

Pour redéfinir L1TF à ses valeurs par défaut :
ansible-playbook -e "HOSTS=webservers RESET=1" CVE-2018-3620-apply_settings.yml

Télécharger le système d'atténuation de risque par les playbooks

CVE-2018-3620-fix_disable_ht.yml  Detached GPG signature

CVE-2018-3620-apply_settings.yml  Detached GPG signature

Action

Il est fortement recommandé aux clients de Red Hat qui utilisent des versions affectées de ces produits Red Hat de les mettre à jour dès que des errata sont disponibles. Les clients sont instamment priés d'appliquer immédiatement les mises à jour disponibles et d'activer les mesures de mitigation qu'ils jugent 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/machine virtuelle devra être éteinte et démarrée à nouveau pour pouvoir reconnaître un nouveau type de hardware.

Mises à jour des produits concernés

*Un abonnement ELS actif est exigé pour pouvoir accéder à ce correctif. Veuillezcontacter l'équipe de vente de Red Hat ou bien, votre représentant commercial particulier pour obtenir plus d'informations si votre compte n'a pas d'abonnement ELS actif.

**Un abonnement EUS actif est exigé pour pouvoir accéder à ce correctif. Veuillezcontacter l'équipe de vente de Red Hat ou bien, votre représentant commercial particulier, pour obtenir plus d'informations si votre compte n'a pas d'abonnement EUS actif.

Qu'est- ce qu'un abonnement Red Hat Enterprise Linux Extended Update Support ?

*Un abonnement AUS actif est exigé pour pouvoir accéder à ce correctif dans RHEL AUS.

Que signifie Support AUS (Advanced mission-critical Update Support) ou prise en charge de mises à jour avancées à mission critique ?

*Un abonnement TUS actif est exigé pour pouvoir accéder à ce correctif dans RHEL TUS.

***** Les abonnés doivent contacter leurs FEO pour obtenir les versions de micro-code/firmware CPU les plus récentes.

Mesures d'atténuation du risque

Les mesures actuelles d'atténuation du risque comprennent l'application des mises à jour logicielles fournisseur combinées aux micro-code/firmware CPU des FEO. Tous les clients Red Hat doivent appliquer les solutions proposées par le fournisseur pour patcher leurs CPU, le système BIOS (si nécessaire) et mettre à jour le noyau dès que des correctifs sont disponibles. Toutes les mesures d'atténuation du risque sont activées par défaut, à l'exception de la désactivation de l'Hyper-Threading, que les clients doivent effectuer manuellement. Il est conseillé aux clients d'adopter une approche basée sur le risque de sécurité lorsqu'ils examinent cette question et tentent de réagir. Les clients devront évaluer le risque de sécurité, l'éventail des mesures d'atténuation de risque, et leurs impacts sur la performance pour créer une stratégie d'atténuation du risque. Les systèmes qui exigent un degré de sécurité et de fiabilité élevés doivent être traités en premier et isolés des systèmes non fiables jusqu'à ce que l'on puisse appliquer des solutions à ces systèmes pour réduire le risque d'exploitation. Les clients désireux d'atténuer ce risque au maximum devront envisager une gestion de la sécurité plus renforcée et éventuellement désactiver l'Hyper-Threading pour clore tous les vecteurs d'attaque.

Mesures d'atténuation du risque / Outils de correction

Pour une réduction de risque lié à « L1 Terminal Fault » maximale, trois changements sont nécessaires : l'inversion des tableaux de pages (une petite modification du noyau qui est fournie et activée par défaut dans les noyaux mis à jour), le vidage du cache de données L1 lors des changements de machines virtuelles, et éventuellement la désactivation du SMT. Chacun de ces changements fournit indépendamment une certaine protection contre les différents aspects d'une attaque.

L'inversion des tableaux de pages (qui n'est PAS la même chose que l' Isolation des tableaux de pages ajoutée pour l'atténuation du risque avec Meltdown) est effectuée par défaut lors de la manipulation d'entrées de tableaux de pages non présentes dans les noyaux mis à jour fournis par Red Hat.

Le vidage du cache de données L1 est facultatif et peut être implémenté par une mise à jour du microcode ou du noyau. Il est actuellement activé par défaut lors de l'exécution de machines virtuelles invitées, mais peut être contrôlé par l'utilisateur par le biais des paramètres du noyau.

SMT Disable est utilisé en option pour sécuriser un environnement partagé non sécurisé exécutant des machines virtuelles. Cela passe par des modifications logicielles au niveau du noyau pour ajouter une nouvelle interface de contrôle. Il est également possible de désactiver l' Hyper-threading d'Intel dans le firmware du BIOS, mais c'est beaucoup plus difficile et ce n'est pas l'approche conseillée.

La solution implique cette approche tripartite car cette faille a trois facteurs contribuant :

1. Une entrée PTE (de l'anglais Page table Entry) non présente (P flag = 0) OU qui a un set de bits réservés contient une adresse physique non initialisée, et cette adresse physique is mise en cache dans le cache de données L1.
2. Les mises à jour causées par les opérations spéculatives dans le cache de données L1 ne sont pas effacées. On peut s'en rendre compte grâce à un processus supplémentaire.
3. Les multi-threads simultanés (SMT) partagent le moteur d'exécution et les caches des processeurs on-chip comme les caches de données L1 et TLB.

Inversion des tableaux de pages :

Le processeur accède spéculativement à l'adresse physique à partir d'un PTE Non présent et si le contenu de cette adresse physique est mis en cache dans le cache de données L1, l'accès à la mémoire réussit. Par conséquent, si le contenu de l'adresse physique n'est pas mis en cache, l'accès à la mémoire n'entraîne pas de fuite de données. La façon d'atténuer le risque d'inversion des tableaux de pages est de mettre à jour l'adresse physique dans les PTE Non présents en réglant les bits d'adresse d'ordre élevé, de façon à pointer vers une adresse physique qui n'est pas en mémoire et/ou qui n'est pas mise en cache. Ainsi, son contenu ne peut pas être présent dans le cache de données L1.

Le paquet du noyau mis à jour montre l'état actuel du système via l'interface sysfs comme indiqué :

# cat /sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: SMT vulnerable, L1D conditional cache flushes
#

Vidage du Cache de données L1 :

Les processeurs Intel x86 offrent un IA32_FLUSH_CMD Machine Specific Register (MSR), lorsque le microcode mis à jour est installé sur le système. Il peut être utilisé pour invalider le cache de données L1. On peut observer le support de IA32_FLUSH_CMD MSR via les indicateurs de /proc/cpuinfo OU via la commande lscpu(1) qui liste les indicateurs de CPU :

# lscpu
Flags:    … ssbd ibrs ibpb stibp spec_ctrl intel_stibp flush_l1d
#

Si l'indicateur flush_l1d n'est pas disponible, veuillez confirmer que le microcode mis à jour est installé sur le système et que le système a été redémarré.

Si le microcode mis à jour n'est pas installé, l'indicateur flush_l1d ne sera pas disponible. Alors, le noyau mis à jour vide toujours le cache de données L1 dans le logiciel. Ceci sera plus lent par rapport à l'interface de hardware flush_l1d .

Le paquet de noyau mis à jour introduit les paramètres suivants de noyau et du module KVM pour contrôler les mesures d'atténuation de risque pour L1TF :

l1tf=[full/full,force/flush/flush,nosmt/flush,nowarn/off]

Il s'agit d'un paramètre d'amorçage du noyau pour contrôler le problème L1TF sur les processeurs affectés. Il peut prendre l'une des valeurs suivantes

full:  permet toutes les mesures d'atténuation du risque pour le problème L1TF.

• Active le vidage du cache de données L1 à chaque opération d'entrée de VM.
• Désactivation de l' Hyper-Threading (SMT).

Le vidage du cache de données L1 et le SMT peuvent tous deux être contrôlés au moment de l'exécution, après l'amorçage, via l'interface sysfs.

full,force:  permet toutes les mesures d'atténuation du risque pour le problème L1TF.

• Active le vidage du cache de données L1 à chaque opération d'entrée de VM.
• Désactivation de l' Hyper-Threading (SMT).

Le paramètre « force » empêche les utilisateurs de désactiver les mesure d'atténuation du risque L1TF ci-dessus via l'interface sysfs. Les utilisateurs ne peuvent pas activer l'hyper-threading (SMT) au moment de l'exécution.

flush: only enable L1 data cache flush

• Active l'atténuation du risque de vidage du cache des données L1 par défaut, qui consiste à vider conditionnellement le cache de données L1.
• Ne désactive pas l' Hyper-Threading (SMT).

Ils peuvent tous deux être contrôlés via l'interface sysfs. L'hyperviseur (KVM) émet un avertissement si un invité est démarré avec des configurations non sécurisées telles qu'avec le SMT activé OU le vidage de cache de données L1 désactivé.

flush,nosmt: disables the Hyper-Threading (SMT)

• Permet la solution de mitigation de vidage conditionnelle du cache de données L1
• Désactiver l' Hyper-Threading (SMT).

Ils peuvent tous deux être contrôlés via l'interface sysfs. L'hyperviseur (KVM) émet un avertissement si un invité est démarré avec des configurations non sécurisées telles qu'avec le SMT activé OU le vidage de cache de données L1 désactivé.

flush,nowarn: similaire à l'option de vidage ci-dessus, à part les avertissements du module KVM concernant les invités dont la configuration n'est pas sécurisée qui sont supprimés.

off : désactive les mitigations niveau hyperviseur, c'est-à-dire que KVM ne videra pas le cache de données L1 à l'entrée de la VM.

La valeur par défaut du paramètre l1tf boot est définie sur l'option d'atténuation de risque de vidage ci-dessus.

kvm-intel.vmentry_l1d_flush : paramètre du module KVM pour contrôler les opérations de vidage du cache de données L1 à chaque entrée de la VM. Il peut avoir des valeurs possibles comme indiqué ici :

   always     vidage de cache L1D à chaque VMENTER.
   cond       vidage de cache L1D conditionel.
   never      désactive la mitigation par vidage du cache L1D.

cond essaie d'éviter les vidages de cache L1D sur VMENTER si le code exécuté entre VMEXIT et VMENTER est considéré comme sûr, c'est-à-dire qu'il n'apporte aucune
information intéressante dans L1D qui puisse être exploitée.

        # cat  /sys/module/kvm_intel/parameters/vmentry_l1d_flush
       cond
       #

Ce paramètre est réglé par défaut sur « cond by default »; il effectue un vidage du cache de données L1 sur des instances d'entrée sélectives de la VM. Cela devrait contribuer à réduire l'impact du vidage du cache de données L1 sur la performance.

Contrôle SMT :

Lorsque la technologie de multithreading ou Hyper-Threading simultané est utilisée, des threads non liés s'exécutant sur le même cœur et partageant les ressources de cache du processeur peuvent lire les données de l'autre dans le cache de données L1 en exploitant la vulnérabilité L1TF. Si vous utilisez un environnement partagé non fiable, vous devrez envisager de désactiver le SMT dans le cadre de votre stratégie d'atténuation du risque. En général, le SMT peut être activé ou désactivé à partir du Bios système.

Les paquets de noyau mis à jour comprennent un nouveau paramètre de ligne de commande « nosmt ».

nosmt : désactive le multithreading simultané (SMT). Il peut être réactivé au moment de l'exécution via une interface sysfs.

nosmt=force : désactive le multithreading simultané (SMT). Il ne peut pas être réactivé au moment de l'exécution.

REMARQUE : il existe des contrôles dans l'interface sysfs du noyau pour gérer le multithreading au moment de l'exécution, bien que leur utilisation puisse conduire à des comportements erronés lorsque le SMT est réactivé. Par conséquent, il est fortement recommandé d'utiliser les paramètres du BIOS ou les paramètres d'amorçage du noyau énumérés ci-dessus pour activer/désactiver le SMT. Les indicateurs de durée d'exécution ne sont décrits ici qu'à titre de référence :

/sys/devices/system/cpu/smt/active
/sys/devices/system/cpu/smt/control

Le fichier actif ci-dessus est une interface en lecture seule. Lorsque le fichier actif contient «1», cela signifie que le SMT est activé et que les threads frères sont en ligne. Lorsque le noyau est démarré avec le paramètre «nosmt», il écrit essentiellement «0» dans le fichier actifci-dessus.

Le fichier de contrôle mentionné ci-dessus est une interface de lecture/écriture pour contrôler le SMT. Il peut avoir les valeurs suivantes :

on : le SMT est activé. Active les threads frères et sœurs s'ils étaient hors ligne.
off : le SMT est désactivé. Désactiver les threads frères s'ils étaient en ligne.
forceoff : le SMT est désactivé de force et ne peut pas être modifié. Il ne peut pas être
contrôlé ni modifié au moment de l'exécution.
notsupporte : le processeur ne prend pas en charge l'Hyper-Threading (SMT).

Désactiver EPT :

La désactivation de l'EPT (Extended Page Tables) pour les invités KVM atténue le problème L1TF, car elle permet essentiellement au VMM/Hyperviseur de gérer les traductions d'adresses pour l'invité. Si l'EPT est désactivé, il n'est pas nécessaire de désactiver Hyper-Threads (SMT) et de vider le cache de données L1 comme indiqué ci-dessus.

Veuillez noter que la désactivation de l'EPT entravera considérablement les performances du système. Ce n'est peut-être pas une option viable.

L'EPT peut être désactivé dans l'hyperviseur via le paramètre kvm-intel.ept . Il est activé par défaut.

Red Hat recommande aux clients d'appliquer la mise à jour du microcode/firmware conseillée par votre fournisseur de matériel ou de processeur et d'installer ces noyaux mis à jour dès que possible. Les mises à jour logicielles peuvent être appliquées indépendamment de celles du microcode hardware, mais ne prendront effet que lorsque le firmware du processeur aura été mis à jour.

Tuned

Les nouveaux noyaux L1TF fournissent des contrôles qui permettent à l'utilisateur de désactiver l'Hyper-Threading soit au moment de l'exécution, soit lors de l'amorçage du noyau. Si l'une de ces deux méthodes est utilisée et que le système exécute l'un des quatre profils syntonisés (tuned) suivants :

      cpu-partitioning    
      realtime
      realtime-virtual-host
      realtime-virtual-guest

alors une mise à jour syntonisée (tuned) sera nécessaire. Ceci n'affecte que RHEL 7.4z et 7.5z. Une mise à jour n'est pas nécessaire si Hyper-Threading est désactivé dans le BIOS.