La Fibre

Datacenter et équipements réseaux => Équipements réseaux => hébergement Serveurs => Discussion démarrée par: vivien le 14 mai 2019 à 22:01:37

Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 22:01:37
MDS (Microarchitectural Data Sampling): Nouvelle vague de vulnérabilités autour de l'exécution spéculative dans les CPU Intel

Ces vulnérabilités résident dans l’implèmentation de l’exécution spéculative, où le microprocesseur essaie de deviner quelles instructions seront éventuellement nécessaires. Ils exploitent la possibilité de lire des tampons de données trouvés entre différentes parties du processeur.

Quatre CVE ont été assignés pour couvrir les différents cas de fuites de données :
- ZombieLoad CVE-2018-12130 pour la fuite de données déjà chargées à partir du buffer de remplissage d'un processeur (MFBDS)
- Fallout CVE-2018-12126 pour la fuite de données stockées dans les buffers (MSBDS)
- RIDL CVE-2018-12127 pour la fuite provenant de divers buffers internes au microprocesseur (MLPDS)
- RIDL CVE-2019-11091 pour la fuite de données dans la mémoire uncacheable (MDSUM)

(https://lafibre.info/images/logo/logo_zombieload.png)

=> https://cpu.fail/

L'annonce d'Intel: https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html

L'analyse de Canonical (éditeur d'Ubuntu) :

Il a été découvert que le contenu de la mémoire précédemment stockée dans des mémoires microarchitecturales d’un cœur de processeur Intel pouvait être exposé à un processus malveillant s’exécutant sur le même cœur de processeur par le biais d’un canal latéral d’exécution spéculatif. Un attaquant local pourrait accéder au contenu obsolète des mémoires tampon de stockage, des ports de chargement et des tampons de remplissage pouvant contenir des données appartenant à un autre processus ou des données provenant d'un contexte de sécurité différent. En conséquence, une exposition de mémoire inattendue peut se produire entre les processus de l'espace utilisateur, entre le noyau et l'espace de l'utilisateur, entre les ordinateurs virtuels ou entre un ordinateur virtuel et l'environnement hôte.

MDS diffère des autres attaques de canal secondaire d’exécution spéculatives récentes en ce que l’attaquant ne peut pas cibler des données spécifiques. L'attaquant peut échantillonner périodiquement le contenu des tampons mais ne contrôle pas les données présentes dans les tampons lors du prélèvement de l'échantillon. Par conséquent, un travail supplèmentaire est nécessaire pour collecter et reconstruire intégralement les données en un ensemble de données significatif.

Les processeurs d'autres fournisseurs ne sont apparemment pas affectés par les MDS.

Intel a fourni des mises à jour du microcode qui, associées aux noyaux mis à jour, atténuent les vulnérabilités dans certaines situations. La technique sous-jacente utilisée pour résoudre les quatre problèmes est la même. Le noyau exécute une instruction spécifique qui efface tous les tampons microarchitecturaux affectés. Le noyau doit exécuter l'instruction à différents moments pour chaque vulnérabilité d'échantillonnage de données. Dans certaines situations, la suppression des mémoires tampons empêchera les adversaires d’accéder aux données présentes.

Les mises à jour du noyau et du package intel-microcode correspondantes corrigent pleinement les failles de la MDS si votre processeur ne prend pas en charge la technologie Hyper-Threading, également appelée Symmetric Multi-Threading (SMT).

Les MDS ne sont pas totalement contrôlées si votre processeur prend en charge l'Hyper-Threading et si l'Hyper-Threading est activé.

Voici un exemple de charges de travail nécessitant la désactivation de l'Hyper-Threading: Un système qui héberge des machines virtuelles provenant de domaines de sécurité variés et / ou dont le propriétaire du système ne fait pas totalement confiance. Un programme malveillant dans une machine virtuelle peut extraire des secrets d’autres machines virtuelles ou de l’hôte de virtualisation lui-même.

L'option de démarrage du noyau suivante peut être utilisée pour désactiver l'Hyper-Threading des processeurs affectés. Cette configuration fournit une atténuation complète sur les systèmes mis à jour: mds = full, nosmt



De nouveaux microcode sont disponible, Dell a par exemple diffusé des mises à jour UEFI pour de nombreux PC.

Intel a prévu des mises à jour pour tous les processeurs sortis depuis 2012 (à part certains Atom).
Certains processeurs de 2011 sont aussi corrigés, mais aucun de 2010 et avant.

Un résumé hors gamme "Atom" :
- famille de processeurs Sandy Bridge (core de 2ème génération par exemple Core i3/i5/i7 2xxx) et plus récents => correctifs présents
- famille de processeurs Nehalem, Westmer (core de 1ère génération) ou plus anciens => pas de correctifs

Liste des processeurs qui sont mis à jour et de ceux qui ne seront pas mis à jour :
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/materiel/201905_intel_microcode_update_guide.jpg) (https://lafibre.info/images/materiel/201905_intel_microcode_update_guide.pdf)

Aucun mécanisme de secours logiciel n'est disponible pour les processeurs qui n'ont pas reçu de mises à jour de microcode par Intel. Une atténuation n'est possible que si Intel a fourni une mise à jour du microcode à votre processeur.

Pour ceux qui ne peuvent pas faire la mise à jour de leur BIOS / UEFI,  de nombreux systèmes d'exploitation vont diffuser des mises à jour du micro-code du CPU (installé à chaque reboot).
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 22:03:19
Ubuntu : Les correctifs (micro-code + nouveau noyau) pour Ubuntu sont en ligne pour toutes distributions encore maintenues
   
Mise à jour du microcode pour Ubuntu:
- Ubuntu 19.04 => intel-microcode 3.20190514.0ubuntu0.19.04.1
- Ubuntu 18.10 => intel-microcode 3.20190514.0ubuntu0.18.10.1
- Ubuntu 18.04 LTS => intel-microcode 3.20190514.0ubuntu0.18.04.2
- Ubuntu 16.04 LTS => intel-microcode 3.20190514.0ubuntu0.16.04.1
- Ubuntu 14.04 ESM => intel-microcode 3.20190514.0ubuntu0.14.04.1

Il faut également une mise à jour du noyau Linux :
- Ubuntu 19.04 => linux-image-5.0.0-15-generic 5.0.0-15.16
- Ubuntu 18.10 => linux-image-4.18.0-20-generic 4.18.0-20.21
- Ubuntu 18.04 LTS => linux-image-4.15.0-50-generic 4.15.0-50.54 ou linux-image-4.18.0-20-generic 4.18.0-20.21
- Ubuntu 16.04 LTS => linux-image-4.4.0-148-generic 4.4.0-148.174 ou  linux-image-4.15.0-50-generic 4.15.0-50.54
- Ubuntu 14.04 ESM => linux-image-3.13.0-170-generic 3.13.0-170.220 ou linux-image-4.4.0-148-generic 4.4.0-148.174
- Ubuntu 12.04 ESM => linux-image-3.2.0-140-generic 3.2.0-140.186 ou  linux-image-3.13.0-140-generic 3.13.0-140.186


(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_mise_a_jour_faille_mds.png)



Comment faire si mon Linux n'a pas installé le package Intel-microcode ?

Pour les PC avec interface graphique, il faut activer l’utilisation du microcode Intel dans les pilotes additionnels :
(https://lafibre.info/testdebit/ubuntu/201512_microcode_intel_ubuntu_1510.png)

A priori, c'est activé par défaut depuis Ubuntu 16.04.
Il faut par contre l'activer manuellement sur des anciens Linux ou des distribution comme Debian.[/size]



Sur un serveur Ubuntu server comment faire ?

C'est simple :
sudo apt install intel-microcode

Il faut ensuite redémarrer le serveur.

intel-microcode est un paquet qui installe iucode-tool




Sur un serveur Debian, comment faire ?

La documentation est sur https://wiki.debian.org/Microcode

Il faut activer les dépôts "contrib" et "non-free"  dans /etc/apt/sources.list

Par exemple :
deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free
deb  http://deb.debian.org/debian stretch main contrib non-free
deb-src  http://deb.debian.org/debian stretch main contrib non-free

Puis :
sudo apt update
sudo apt install intel-microcode


Il faut ensuite redémarrer le serveur.
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 22:09:03
Comment vérifier si on est affecté sous Linux ?

En regardant le fichier /sys/devices/system/cpu/vulnerabilities/mds :

cat /sys/devices/system/cpu/vulnerabilities/mds


- Si le fichier n'existe pas, car cela indique que votre noyau n'a pas mis en place de mesures d'atténuation pour MDS : le système est alors vulnérable

- Not affected : Les processeurs qui ne sont pas vulnérables à MDS (par exemple les microprocesseurs AMD)
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_na.png)

- Mitigation: Clear CPU buffers; SMT disabled : Mitigation ok. Intel Hyper-Threading n'est pas disponible ou il a été désactivé
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_ok.png)

- Mitigation: Clear CPU buffers; SMT vulnerable : Mitigation ok. Un risque subsite avec l'activation de Hyper-Threading, d'où le message "SMT est vulnérable"
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_7.png)
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_5.png)
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_2.png)

- Mitigation: Clear CPU buffers; SMT Host state unknown : Mitigation ok. Le noyau n'est pas en mesure de déterminer de manière fiable si Hyper-Threading est activé lors de son exécution dans un environnement virtuel.

- Vulnerable: Clear CPU buffers attempted, no microcode; SMT vulnerable : Vulnerable: soit le microcode n'a pas été installé, soit le processeur est trop ancien pour qu'Intel développe un microcode. Noyau Linux mis à jour, mais sans microcode mis à jour.
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_3.png)

- Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown : Vulnerable:  le microcode n'a pas été installé + le noyau n'est pas en mesure de déterminer de manière fiable si Hyper-Threading est activé lors de son exécution dans un environnement virtuel.
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_4.png)[/size]
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: alain_p le 14 mai 2019 à 22:19:17
Personnellement, je suis très sceptique sur la sévérité de ces vulnérabilités, qui sont très difficiles à exploiter, et je me demande si le remède ne peut pas potentiellement être pire que le mal, si par exemple il entraine des problèmes de performance. A voir...
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 22:22:54
Sur un ordinateur non virtualisé le risque est faible.

Quand on parle de l'hébergement de serveurs virtualisé, le risque est bien plus élevé.
Tu ne connais pas la personne qui loue la VM à coté...

Extrait tradut en Français de Intel Analysis of Microarchitectural Data Sampling :

Atténuation pour les environnements utilisant le multithreading simultané (SMT)

Le système d'exploitation doit employer deux méthodes différentes pour empêcher un thread d'utiliser MDS pour déduire les valeurs de données utilisées par le thread frère :
- Le premier (planification de groupe) protège contre les attaques d'utilisateurs
- La seconde (entrée synchronisée) protège les données du noyau contre les attaques lorsqu'un thread exécute le code du noyau par un attaquant s'exécutant en mode user sur l'autre thread.

Planification de groupe

Le système d'exploitation peut empêcher un thread frère d'exécuter du code malveillant lorsque le thread actuel traverse des domaines de sécurité. Le planificateur de système d'exploitation peut réduire le besoin de contrôler les threads frères en s'assurant que les charges de travail logicielles partageant le même noyau physique se font mutuellement confiance (par exemple, si elles appartiennent au même domaine de sécurité défini par l'application) ou en veillant à ce que l'autre thread soit inactif.

Le système d'exploitation peut appliquer une telle relation de confiance entre des charges de travail de manière statique (par exemple, via l'affinité des tâches ou cpusets) ou de manière dynamique via un planificateur de groupe dans le système d'exploitation (parfois appelé planificateur principal). Le planificateur de groupe doit préférer les processus avec le même domaine de confiance sur le noyau frère, mais uniquement si aucun autre cœur inactif n'est disponible. Cela peut affecter les décisions d'équilibrage de charge entre les cœurs. Si un processus d'un domaine de confiance compatible n'est pas disponible, le planificateur peut avoir besoin d'inactiver le thread frère.

Système sans planification de groupe : un système à trois cœurs où le cœur 2 exécute des processus provenant de différents domaines de sécurité.
Ces processus pourraient utiliser MDS pour déduire des données protégées les unes des autres.
(https://lafibre.info/images/materiel/201905_intel_vm_core_scheduling_1.png)

Système avec planification de groupe : montre comment un planificateur de groupe supprime la possibilité d'attaques de processus à processus en s'assurant qu'aucun noyau n'exécute des processus de domaines de sécurité différents en même temps.
(https://lafibre.info/images/materiel/201905_intel_vm_core_scheduling_2.png)


Entrée synchronisée à l'anneau 0 et sortie à l'aide d'IPI

Le système d'exploitation doit prendre des mesures lorsque le thread matériel actuel effectue la transition du code user (code de l'application) au code du noyau (mode anneau 0). Cela peut se produire dans le cadre d'événements syscall ou asynchrones tels que des interruptions. Par conséquent, le thread frère peut ne pas être autorisé à s'exécuter en mode user car le code du noyau peut ne pas approuver le code user. Dans une vue simplifiée d'un système d'exploitation, nous pouvons considérer que chaque thread se trouve dans l'un des trois états suivants:
- Idle
- Ring 0 (kernel code)
- User (code de l'application)

La figure ci-dessous montre les transitions d'état permettant de protéger le noyau contre les applications malveillantes :
(https://lafibre.info/images/materiel/201905_intel_vm_core_thread_sched_state.png)

Chaque nœud de la figure ci-dessus montre les états d'exécution possibles des deux threads partageant un cœur physique.

À partir de l'état 1, les deux threads sont inactifs. À partir de cet état, une interruption fera passer le noyau à l'état 2a ou 2b en fonction du thread qui est interrompu. S'il n'y a aucune tâche utilisateur à exécuter, le cœur physique repasse à l'état 1 à la fin de l'interruption. Si l'état d'inactivité est implèmenté à l'aide des états C du processeur, VERW doit être exécuté avant l'entrée dans les états C des processeurs affectés par MSBDS.

À partir de 2a ou 2b, un thread peut commencer à exécuter un processus user. Tant que l'autre thread sur le cœur reste inactif, des atténuations spécifiques à SMT ne sont pas nécessaires lors de la transition de 2a à 3a ou de 2b à 3b, bien que le système d'exploitation doive écraser les tampons en exécutant VERW avant de passer à 3a ou 3b.

En variante, à partir de 2a ou 2b, le noyau physique peut passer à l'état 4 si une interruption réveille le fil frère. Le noyau physique peut éventuellement revenir en 2a ou 2b si cette interruption ne provoque pas l'exécution d'un processus user par le noyau.

À partir de l'état 4, le noyau peut passer à l'état 5 et commencer à exécuter le code user sur les deux threads. Le système d'exploitation doit s'assurer que le passage à l'état 5 empêche le thread qui entre en premier le code user de lancer une attaque sur des données protégées dans les tampons microarchitecturaux de l'autre thread. Le système d'exploitation doit également exécuter VERW sur les deux threads. Il n'y a pas de support matériel pour la transition atomique des deux threads entre les états du noyau et de l'utilisateur. Le système d'exploitation doit donc utiliser les techniques logicielles standard pour synchroniser les threads. Le système d’exploitation doit également veiller à éviter, au niveau des points limites, le chargement de données protégées dans des mémoires tampons microarchitecturales lorsque l’un ou les deux threads passent en mode user. Notez que le noyau ne doit entrer que dans l'état 5 lors de l'exécution de deux threads user du même domaine de sécurité (comme décrit dans la section Planification de groupe ci-dessus).

Le noyau peut entrer dans l'état 6a ou 6b à partir de l'état 5 parce qu'un des threads quitte le mode user ou à partir de l'état 3a ou 3b car une interruption a réveillé un thread de l'état inactif. Lorsqu'il est dans l'état 6a ou 6b, le système d'exploitation doit éviter d'accéder aux données considérées comme protégées vis-à-vis du thread frère en mode user. Si le thread dans l'état du noyau doit accéder à des données protégées, le système d'exploitation doit passer de l'état 6a ou 6b à l'état 4. Le thread dans l'état du noyau doit utiliser une interruption interprocesseur (IPI) pour mettre en contact les deux threads dans l'état du noyau afin d'effectuer la transition. le noyau à l'état 4. Lorsque le thread du noyau est prêt à quitter l'état du noyau (en passant à l'état inactif ou en revenant à l'état user), le thread frère peut être autorisé à quitter la routine de service IPI et à reprendre son exécution. l'utilisateur se déclare lui-même après avoir exécuté un VERW.
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 14 mai 2019 à 22:29:36
Cela concerne-t'il également les PCs sous Windows ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 22:29:39
Oui, c'est un bug matériel, cela concerne tous les systèmes d’exploitation (sauf probablement ceux qui son monotâche, comme MS-DOS).

Microsoft à déployé des mises à jour pour Windows 7, Windows 8 et Windows 10.

Il faut faire par contre attention au microcode, Microsoft ne fournit le microcode que pour le PCs Microsoft (principalement la gamme "surface") : "Si vous possédez un appareil non-Microsoft, nous vous recommandons de contacter votre fabricant OEM pour obtenir cette information."
Aucun mécanisme de secours logiciel n'est disponible pour les processeurs qui n'ont pas reçu de mises à jour de microcode Intel
=> Pour les utilisateurs Windows une mise à jour du BIOS / UEFI est nécessaire.
=> Pour les utilisateurs Linux tout est mis à jour, si la distribution propose bien une mise à jour du microcode.

Maintenant comme évoqué, le risque est bien plus élevé coté serveur qui héberge des VM, d'où la position de ce sujet dans la partie serveur.

Comment vérifier si on a bien le bon microcode ?

Sous linux, il faut faire dmesg | grep microcode

La date du microcode apparaît, elle doit dater de 2019 :

(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_1.png)


Quand il n'y a pas de microcode disponible, voici ce qu'affiche dmesg |grep microcode :

(https://lafibre.info/images/cpu/201905_lscpu_intel_pentium_t2080_yonah.png)
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 14 mai 2019 à 22:56:38
Merci: MàJ cumulative installée.  (https://lafibre.info/images/smileys/@GregLand/ay.gif)
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 23:30:14
Attention : tu dois aussi mettre à jour le BIOS de ton PC pour que cela puisse fonctionner.

Quid des performances ?

Intel a réalisé des tests qui montrent une absence de baisse de performance sauf pour les serveurs de stockage :


(https://lafibre.info/images/materiel/201905_intel_mds_server.png)
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 14 mai 2019 à 23:36:34
Mes propres tests de performances avant / après le patch

J'ai toutefois eu enfin de faire mes propre tests, sur un PC bien plus ancien et bien moins performant avec l'Hyper-Threading non désactivé (car oui le désactiver fait bien baisser les performances, pas de surprise)

J'ai réalisé mes tests sur les 5 technologies de chiffrement utilisées pour transporter du trafic https avec un Core i3-4150 @3.50GHz, processeur intégrant les instructions AES-NI.
Le système d’exploitation est Ubuntu 19.04 et j'ai réalisé le test avant et après la mise à jour micro-code + noyau Linux.

OpenSSL donne des débits en Mo/s pour plusieurs taille de blocs (16 bytes / 64 bytes / 256 bytes / 1024 bytes / 8192 bytes / 16384 bytes) : je prend la valeur la plus élevée entre tous les types de blocs et je recommence deux fois les tests pour prendre le test le plus élevé.

$ openssl speed -elapsed -evp aes-128-cbc --multi 8 : Perte de débit de 0,01% (3134,2 Mo/s vs 3134,0 Mo/s)

$ openssl speed -elapsed -evp aes-256-cbc --multi 8 : Perte de débit de 0,36% (2255,0 Mo/s vs 2246,9 Mo/s)

$ openssl speed -elapsed -evp aes-128-gcm --multi 4 : Perte de débit de 0,04% (7035,2 Mo/s vs 7032,6 Mo/s)

$ openssl speed -elapsed -evp aes-256-gcm --multi 4 : Perte de débit de 0,34% (5421,2 Mo/s vs 5402,7 Mo/s)

$ openssl speed -elapsed -evp chacha20-poly1305 --multi 4 : Perte de débit de 0,07% (4272,3 Mo/s vs 4269,5 Mo/s)

Les tests avec moins de threads sont moins impactés ou non impactés.
=> L'impact du patch sur les performances est donc bien faible


La version d'OPenSSL utilisée est celle d'Ubuntu 19.04 : OpenSSL 1.1.1b  26 Feb 2019.



Liste de sites qui utilisent aes-128-cbc :
centurylink.ca
Liste de sites qui utilisent aes-256-cbc :
sfr.fr
skype.com

Liste de sites qui utilisent aes-128-gcm :
amazon.fr
google.com
youtube.com
orange.fr
ovh.com
securityheaders.com
mozilla.github.io
free.fr
lemonde.fr
vichy.fr
ubuntu.com
debian.org
fr.yahoo.com
cogentco.com
linkedin.com
speedtest.net
vinted.fr
banque-france.fr
psychologies.com
ssllabs.com
mozilla.org
fortuneo.fr
netflix.com
hstspreload.org

Liste de sites qui utilisent aes-256-gcm :
microsoft.com
apple.com
getfedora.org
ionos.fr
paris.fr
lyon.fr
dailymotion.com
leboncoin.fr
bouyguestelecom.fr
qwant.com
scaleway.com
boursorama.com
nperf.com
mycanal.fr
assurance-carte.europ-assistance.fr
k-net.fr
LaFibre.info
1.testdebit.info

Liste de sites qui utilisent chacha20-poly1305 :
tls.imirhil.fr
fr.wikipedia.org
cdiscount.com
fr.libreoffice.org
videolan.org
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 15 mai 2019 à 18:17:13
"openssl speed" c'est du code pur userspace sans aucun syscall ni IPC (comme le "General Compute" d'Intel tant le nombre de threads est inférieur au nombre de threads du CPU), donc c'est normal que les performances ne changent pas.

Les patchs ont des impacts sur les changements de contexte :
 - interruptions
 - appels système
 - basculement d'un processus à un autre (voire thread, je ne sais pas si le kernel fait la différence et évite les séquences d'effacement des buffers dans ce cas)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 15 mai 2019 à 20:31:27
Le test a été réalisé sur un Core i3-4150 : 2 cœurs Hyper-Threading, donc au moins quand je suis en multi 8 bascule d'un processus à un autre.

Par contre tu saurais peut-être me dire pourquoi avec OpenSSL, aes-128-cbc et aes-256-cbc voit ses performances doublées quand on passe de 2 threads à 4threads alors que le CPU n'a que 2 cœurs ! Là l'Hyper-Threading permet de doubler les performances.

Au contraire, avec aes-128-gcm etaes-256-gcm il n'y a aucun gain avec l''Hyper-Threading : les performances sont les mêmes quand on passe de 2 threads à 4threads.


(https://lafibre.info/testdebit/ubuntu/201905_openssl111_performance_core_i3-4150.png)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 15 mai 2019 à 22:44:38
Le test a été réalisé sur un Core i3-4150 : 2 cœurs Hyper-Threading, donc au moins quand je suis en multi 8 bascule d'un processus à un autre.
En effet (ce sont bien 8 processus et non pas 8 threads), et sur ce test Ubuntu qui a CONFIG_HZ=250 (sur le kernel générique) est probablement légèrement moins impacté que Fedora par exemple qui a CONFIG_HZ=1000 donc devrait basculer plus souvent.

Par contre tu saurais peut-être me dire pourquoi avec OpenSSL, aes-128-cbc et aes-256-cbc voit ses performances doublées quand on passe de 2 threads à 4threads alors que le CPU n'a que 2 cœurs ! Là l'Hyper-Threading permet de doubler les performances.

Au contraire, avec aes-128-gcm etaes-256-gcm il n'y a aucun gain avec l''Hyper-Threading : les performances sont les mêmes quand on passe de 2 threads à 4threads.[/size]
Déjà, il faut faire attention, si la fréquence du CPU n'est pas fixée, augmenter la charge peut faire baisser le turbo.
L'hyperthreading est utile :
 - quand on a des tâches qui attendent la mémoire
 - quand on a trop de dépendances dans le flux d'instructions qui empêchent d'extraire le maximum de parallélisme
 - dans certains cas où certaines unités sont saturées et d'autres inutilisées (cas de deux tâches différentes, ce qui n'est pas le cas ici)

Ici, on est dans le second cas, ce qui s'explique en regardant les algorithmes :
 - https://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_(cryptographie)#Encha%C3%AEnement_des_blocs_:_%C2%AB_Cipher_Block_Chaining_%C2%BB_(CBC)
Citer
Un des points négatifs de CBC étant qu'il ne peut pas être parallélisé étant donné que le bloc courant nécessite que le précédent soit chiffré. Il est donc séquentiel.
- https://fr.wikipedia.org/wiki/Galois/Counter_Mode
Le GCM est dérivé du CTR : les opérations (AES+XOR) sur des blocs successifs peuvent être réalisées en même temps car il n'y a aucune dépendance.

D'ailleurs avec openssl, aes-128-ctr donne les même performances que aes-128-gcm (la limite d'exécution des instructions AES-NI probablement).
Mais le code AES-GCM fait aussi l'authentification (GHASH), alors que le code AES-CTR (comme AES-CBC) ne fait que chiffrer.
C'est pour ça que si on veut comparer les deux dans un contexte TLS, il faut faire :
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha1 (850Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha256 (440Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-gcm (5.5Go/s)
=> On voit tout l'intérêt du mode GCM.
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: vivien le 16 mai 2019 à 09:46:49
Compétemment hors sujet, mais tu en pense quoi de chacha20-poly1305 ?
Il semble plus récent et mieux adaptés pour des CPU sans support de l'AES.

Il est utilisé par quelques grands sites :

Liste de sites qui utilisent chacha20-poly1305 :
tls.imirhil.fr
fr.wikipedia.org
cdiscount.com
fr.libreoffice.org
videolan.org

Voici des tests avec un Serveur Xeon Irwindale @2.8Ghz  - 1 cœur – 2 threads
C'est un processeur Xeon dérivé du Pentium 4 (architecture NetBurst, gravé en 90 nm, il est trés proche du Pentium 4 Prescott 2M Extreme Edition : il a 31 étages de pipeline qui doit être vidé en cas de mauvaises prédictions).
OS: Lubuntu 19.04 64 bits - OpenSSL 1.1.1b

Là on voit que l'Hyper-Threading fait baisser les performances de manière dramatique :

openssl speed -elapsed -evp aes-128-cbc : 81,9 Mo/s
openssl speed -elapsed -evp aes-128-cbc --multi 2 : 36,5 Mo/s

openssl speed -elapsed -evp aes-256-cbc : 58,6 Mo/s
openssl speed -elapsed -evp aes-256-cbc --multi 2  : 3,2 Mo/s

openssl speed -elapsed -evp aes-128-gcm : 55,4 Mo/s
openssl speed -elapsed -evp aes-128-gcm --multi 2  : 5,2 Mo/s

openssl speed -elapsed -evp aes-256-gcm : 43,2 Mo/s
openssl speed -elapsed -evp aes-256-gcm --multi 2  : 4,2 Mo/s

openssl speed -elapsed -evp chacha20-poly1305 : 194 Mo/s
openssl speed -elapsed -evp chacha20-poly1305 --multi 2  : 224 Mo/s


(j'ai fais les tests avant de savoir qu'il faut rajouter -hmac-sha256 pour cbc)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 16 mai 2019 à 09:55:31
Descriptif du serveur Serveur Dell Poweredge SC1425 Rack 1U utilisé :

# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 15
Model: 4
Model name: Intel(R) Xeon(TM) CPU 2.80GHz
Stepping: 10
CPU MHz: 2799.964
BogoMIPS: 5599.92
L1d cache: 16K
L2 cache: 2048K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl cpuid pni dtes64 monitor ds_cpl cid cx16 xtpr lahf_lm pti

Les tests ont été fait sous Linux, mais la machine accepte Windows 10 (c'est l'une des plus vieux serveurs a accepter Windows 10, les générations d'avant refusent)
(https://lafibre.info/images/cpu/201905_cpu-z_intel_xeon_irwindale.png)

Pas de PCI Express sur ce serveur, mais du PCI 64bits utilisé par la carte Adaptec

Voici le lspci -tv :

# lspci -tv
-[0000:00]-+-00.0  Intel Corporation E7520 Memory Controller Hub
           +-02.0-[01-03]--+-00.0-[02]----04.0  Intel Corporation 82541GI Gigabit Ethernet Controller
           |               \-00.2-[03]--+-07.0  Adaptec ASC-39320(B) U320 w/HostRAID
           |                            \-07.1  Adaptec ASC-39320(B) U320 w/HostRAID
           +-1d.0  Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1
           +-1d.1  Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2
           +-1d.7  Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
           +-1e.0-[04]--+-03.0  Intel Corporation 82541GI Gigabit Ethernet Controller
           |            \-0d.0  Advanced Micro Devices, Inc. [AMD/ATI] RV100 [Radeon 7000 / Radeon VE]
           +-1f.0  Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
           \-1f.1  Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 16 mai 2019 à 10:00:44
lspci -vv :
# lspci -vv
00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 09)
        Subsystem: Dell PowerEdge SC1425
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Capabilities: [40] Vendor Specific Information: Len=05 <?>
        Kernel modules: e752x_edac

00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Bus: primary=00, secondary=01, subordinate=03, sec-latency=0
        I/O behind bridge: 0000c000-0000efff
        Memory behind bridge: fe500000-feafffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] MSI: Enable- Count=1/2 Maskable- 64bit-
                Address: fee00000  Data: 0000
        Capabilities: [64] Express (v1) Root Port (Slot-), MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0
                        ExtTag- RBE-
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 256 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #2, Speed 2.5GT/s, Width x8, ASPM L0s, Exit Latency L0s <4us, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
                RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal+ PMEIntEna+ CRSVisible-
                RootCap: CRSVisible-
                RootSta: PME ReqID 0000, PMEStatus- PMEPending-
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
        Kernel driver in use: pcieport

00:1d.0 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Dell PowerEdge SC1425
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 4: I/O ports at ace0 [size=32]
        Kernel driver in use: uhci_hcd

00:1d.1 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Dell PowerEdge SC1425
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 4: I/O ports at acc0 [size=32]
        Kernel driver in use: uhci_hcd

00:1d.7 USB controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
        Subsystem: Dell PowerEdge SC1425
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin D routed to IRQ 23
        Region 0: Memory at feb00000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Debug port: BAR=1 offset=00a0
        Kernel driver in use: ehci-pci

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=32
        I/O behind bridge: 0000b000-0000bfff
        Memory behind bridge: fe300000-fe4fffff
        Prefetchable memory behind bridge: f0000000-f7ffffff
        Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Kernel driver in use: lpc_ich
        Kernel modules: intel_rng, lpc_ich

00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller (rev 02) (prog-if 8a [ISA Compatibility mode controller, supports both channels switched to PCI native mode, supports bus mastering])
        Subsystem: Dell PowerEdge SC1425
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
        Latency: 0
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at 01f0 [size=8]
        Region 1: I/O ports at 03f4
        Region 2: I/O ports at 0170 [size=8]
        Region 3: I/O ports at 0374
        Region 4: I/O ports at fc00 [size=16]
        Region 5: Memory at 40000000 (32-bit, non-prefetchable) [size=1K]
        Kernel driver in use: ata_piix
        Kernel modules: pata_acpi

01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=01, secondary=02, subordinate=02, sec-latency=32
        I/O behind bridge: 0000e000-0000efff
        Memory behind bridge: fe900000-feafffff
        Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [44] Express (v1) PCI-Express to PCI/PCI-X Bridge, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- SlotPowerLimit 0.000W
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- BrConfRtry-
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s, Exit Latency L0s unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
        Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [6c] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d8] PCI-X bridge device
                Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=conv
                Status: Dev=01:00.0 64bit- 133MHz- SCD- USC- SCO- SRD-
                Upstream: Capacity=65535 CommitmentLimit=65535
                Downstream: Capacity=65535 CommitmentLimit=65535
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
        Capabilities: [300 v1] Power Budgeting <?>

01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Bus: primary=01, secondary=03, subordinate=03, sec-latency=64
        I/O behind bridge: 0000c000-0000dfff
        Memory behind bridge: fe700000-fe8fffff
        Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [44] Express (v1) PCI-Express to PCI/PCI-X Bridge, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE- SlotPowerLimit 0.000W
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- BrConfRtry-
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x8, ASPM L0s, Exit Latency L0s unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x8, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
        Capabilities: [5c] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [6c] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d8] PCI-X bridge device
                Secondary Status: 64bit+ 133MHz+ SCD- USC- SCO- SRD- Freq=133MHz
                Status: Dev=01:00.2 64bit- 133MHz- SCD- USC- SCO- SRD-
                Upstream: Capacity=65535 CommitmentLimit=65535
                Downstream: Capacity=65535 CommitmentLimit=65535
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
        Capabilities: [300 v1] Power Budgeting <?>

02:04.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
        Subsystem: Dell PRO/1000 MT Network Connection
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (63750ns min), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at fe9e0000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at ecc0 [size=64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=1
                Status: Dev=00:00.0 64bit- 133MHz- SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
        Kernel driver in use: e1000
        Kernel modules: e1000

03:07.0 RAID bus controller: Adaptec ASC-39320(B) U320 w/HostRAID (rev 10)
        Subsystem: Dell ASC-39320(B) U320 w/HostRAID
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (10000ns min, 6250ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at dc00 [disabled] [size=256]
        Region 1: Memory at fe7fe000 (64-bit, non-prefetchable) [size=8K]
        Region 3: I/O ports at d800 [disabled] [size=256]
        Expansion ROM at fe800000 [disabled] [size=512K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a0] MSI: Enable- Count=1/2 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [94] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=8
                Status: Dev=03:07.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=8 DMCRS=16 RSCEM- 266MHz- 533MHz-
        Kernel driver in use: aic79xx
        Kernel modules: aic79xx

03:07.1 RAID bus controller: Adaptec ASC-39320(B) U320 w/HostRAID (rev 10)
        Subsystem: Dell ASC-39320(B) U320 w/HostRAID
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (10000ns min, 6250ns max), Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 19
        Region 0: I/O ports at d400 [disabled] [size=256]
        Region 1: Memory at fe7fc000 (64-bit, non-prefetchable) [size=8K]
        Region 3: I/O ports at d000 [disabled] [size=256]
        Expansion ROM at fe700000 [disabled] [size=512K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a0] MSI: Enable- Count=1/2 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [94] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=8
                Status: Dev=03:07.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=8 DMCRS=16 RSCEM- 266MHz- 533MHz-
        Kernel driver in use: aic79xx
        Kernel modules: aic79xx

04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)
        Subsystem: Dell PRO/1000 MT Network Connection
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (63750ns min), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at fe3e0000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at bcc0 [size=64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [e4] PCI-X non-bridge device
                Command: DPERE- ERO+ RBC=512 OST=1
                Status: Dev=00:00.0 64bit- 133MHz- SCD- USC- DC=simple DMMRBC=2048 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
        Kernel driver in use: e1000
        Kernel modules: e1000

04:0d.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV100 [Radeon 7000 / Radeon VE] (prog-if 00 [VGA controller])
        Subsystem: Dell PowerEdge SC1425
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- Stepping+ SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (2000ns min), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at b800 [size=256]
        Region 2: Memory at fe3d0000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: radeon
        Kernel modules: radeonfb, radeon
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: hwti le 16 mai 2019 à 10:13:21
Compétemment hors sujet, mais tu en pense quoi de chacha20-poly1305 ?
Il semble plus récent et mieux adaptés pour des CPU sans support de l'AES.
Je ne suis pas expert sécurité, donc je me garderais de porter un jugement sur la résistance potentielle aux attaques de ce chiffrement.
C'est une solution récente (donc qui a à la fois bénéficié de l'avancée des recherches en cryptographie, mais sur laquelle on a forcèment moins de recul), conçue par un chercheur reconnu, et qui semble être à la mode.

Concernant les performances, c'est effectivement un bon choix dès qu'il n'y a pas d'AES accéléré. C'est même la seule option pour Wireguard par exemple (ce qui est plus critiquable car beaucoup de CPU ARMv8 ont les extensions crypto qui accélèrent l'AES, alors que chacha20-poly1305 doit se contenter d'une implèmentation qui certes utilise NEON mais est plus lente).
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 16 mai 2019 à 15:08:22
Pour ceux qui se demandent si les précédentes vulnérabilités d'exécution spéculative ont été corrigées en hardware dans les nouveau CPU, voici la réponse :

(https://lafibre.info/images/materiel/201905_intel_vulnerabilites_execution_speculative.png)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: jack le 16 mai 2019 à 18:11:45
N'y a-t-il pas de nombreux "fix" hardware qui sont bien plus dommageable que les "fix" software ?
Je parle en terme de performance
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: underground78 le 16 mai 2019 à 19:30:06
N'y a-t-il pas de nombreux "fix" hardware qui sont bien plus dommageable que les "fix" software ?
Je parle en terme de performance
Ça m'étonnerait. L'objectif est justement de contourner le problème de sécurité tout en évitant la pénalité induite par le correctif logiciel.
Titre: MDS: Nouvelle vague de vulnérabilité d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 16 mai 2019 à 20:41:49
Attention : tu dois aussi mettre à jour le BIOS de ton PC pour que cela puisse fonctionner...
Ça, je ne sais pas comment faire.  (https://lafibre.info/images/smileys/@GregLand/bk.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 16 mai 2019 à 21:10:20
https://blogs.oracle.com/linux/an-update-on-meltdown-and-enhanced-ibrs.
Donc pour ce qui est des Cascade Lake :
 - Meltdown (Variant 3) et L1TF (Variant 5) sont donc corrigés (impossible de savoir si ça a coûté des performances)
 - Spectre (Variant 2) a un meilleur contournement HW ("Mitigation: Enhanced IBRS" une fois au boot), mais on a toujours "Filling RSB on context switch" et "Enabling conditional Indirect Branch Prediction Barrier" (donc un support SW nécessaire)
 - Speculative Store Bypass (Variant 4) n'est pas corrigé (il y a le support de SSBD dans le microcode intégré, Linux l'utilise pour certains processus uniquement)
 - d'après https://software.intel.com/security-software-guidance/insights/deep-dive-cpuid-enumeration-and-architectural-msrs#MDS-CPUID, les stepping 5 sont affectés par MSBDS et MLPDS, les stepping 6 et 7 ne sont pas affectés

Pour les CPU grand public, compte tenu des gammes c'est compliqué de rechercher l'information, je ne sais pas si certains ont la correction Meltdown/L1TF (flag RDCL_NO).
En tout cas, il n'existe aucun CPU avec une correction de Spectre, ni à priori de Speculative Store Bypass (par correction, j'entends quelque chose qui fonctionnerait sans code dans le kernel).
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 18 mai 2019 à 10:19:20
D'ailleurs avec openssl, aes-128-ctr donne les même performances que aes-128-gcm (la limite d'exécution des instructions AES-NI probablement).
Mais le code AES-GCM fait aussi l'authentification (GHASH), alors que le code AES-CTR (comme AES-CBC) ne fait que chiffrer.
C'est pour ça que si on veut comparer les deux dans un contexte TLS, il faut faire :
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha1 (850Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-cbc-hmac-sha256 (440Mo/s pour moi)
 - openssl speed -elapsed -evp aes-128-gcm (5.5Go/s)
=> On voit tout l'intérêt du mode GCM.

J'ai commencé mes tests sur un nouveau processeur (enfin un très vieux : AMD Sempron 2800+, Modèle Palermo 90nm sur Socket 754 : c'est le premier Sempron 64bits.
(https://lafibre.info/images/cpu/201905_cpu-z_amd_sempron_palermo_socket754.png)

Coté système d'exploitation, j'ai mis un Ubuntu 19.04 64bits nouvellement installé.

Mes tests habituels passent bien :
openssl speed -elapsed -evp aes-128-cbc : 109,5 Mo/s
openssl speed -elapsed -evp aes-256-cbc : 81,4 Mo/s
openssl speed -elapsed -evp aes-128-gcm : 36,8 Mo/s
openssl speed -elapsed -evp aes-256-gcm : 28,2 Mo/s
openssl speed -elapsed -evp chacha20-poly1305 : 168,6 Mo/s

Exemple :
$ openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 6409762 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 2032042 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 539577 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 309662 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 40109 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 19996 aes-128-cbc's in 3.00s
OpenSSL 1.1.1b  26 Feb 2019
built on: Wed Apr  3 10:50:23 2019 UTC
options:bn(64,64) rc4(8x,int) des(int) aes(partial) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-uEA50R/openssl-1.1.1b=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      34185.40k    43350.23k    46043.90k   105697.96k   109524.31k   109204.82k

Mais impossible de faire :
openssl speed -elapsed -evp aes-128-cbc-hmac-sha1
openssl speed -elapsed -evp aes-128-cbc-hmac-sha256

$ openssl speed -elapsed -evp aes-128-cbc-hmac-sha1
speed: aes-128-cbc-hmac-sha1 is an unknown cipher or digest
$ openssl speed -elapsed -evp aes-128-cbc-hmac-sha256
speed: aes-128-cbc-hmac-sha256 is an unknown cipher or digest
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 18 mai 2019 à 19:01:34
J'ai essayé sur d'autres ordinateurs, en gardant toujours le même logiciel (Ubuntu 19.04) et semble que les ordinateurs sans les instructions AES n'arrivent pas a exécuter les deux tests ci-dessous :

openssl speed -elapsed -evp aes-128-cbc-hmac-sha1
openssl speed -elapsed -evp aes-128-cbc-hmac-sha256
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 18 mai 2019 à 21:13:56
En effet, ces deux EVP combinés ne sont pas implèmentées sans AES-NI, le code SSL semble séparer les deux opérations dans ce cas, ce qui ne peut pas être testé via "openssl speed".

Je suppose qu'on pourrait utiliser openssl s_server et s_client, mais ce n'est pas immédiat (il faut générer un certificat), et on aurait le chiffrement et le déchiffrement en même temps, et donc il faudrait au moins 2 coeurs pour faire un test correct.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 23 mai 2019 à 22:37:46
Les microcodes Intel pour l’atténuation des vulnérabilités d'exécution spéculative MDS qui manquaient lors du dernier patch tuesday sont arrivés :

(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_mise_a_jour_faille_mds_2.png)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 23 mai 2019 à 22:51:21
Et pour Win7 ?  (https://lafibre.info/images/smileys/@GregLand/cs.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 24 mai 2019 à 06:55:31
Pour Windows 10, Microsoft va distribuer les microcodes. J'ai par contre un peu de mal a savoir si c'est via une mise à jour de l'UEFI/BIOS via Windows Update qui ne concernerait que certains PC de grande marque ou si c'est comme sous Linux, une distribution de microcodes qui sont installé a chaque démarrage dans le CPU (cette méthode permettant de traiter tous les PC / serveurs).

Pour Windows 7 la situation est claire : il faut mettre à jour soit même son UEFI/BIOS pour être protégé. Microsoft demande "obtenir les mises à jour de microcode pour les périphériques Intel auprès de leur OEM" soit de leur fabriquant de PC.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 24 mai 2019 à 09:35:18
Tests indépendants (Phoronix) montrant l'impact sur les performances de la mitigation MDS : https://www.phoronix.com/scan.php?page=news_item&px=Haswell-Xeon-Zombie-Load-Ref
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 24 mai 2019 à 14:17:58
Citation de: vivien link=topic=37856.msg654791#msg654791 date=1558673731...Pour Windows 7 la situation est claire : [b
il faut mettre à jour soit même son[/b] UEFI/BIOS pour être protégé. Microsoft demande "obtenir les mises à jour de microcode pour les périphériques Intel auprès de leur OEM" soit de leur fabriquant de PC.
Oui mais, comment faire ?  (https://lafibre.info/images/smileys/@GregLand/cs.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 24 mai 2019 à 15:52:26
Il faut aller sur le site du fabricant de son PC (ou de sa carte mère si c'est un PC assemblé) et chercher le "support"  puis "Pilotes et téléchargement"

Dell : https://www.dell.com/support/home/fr/fr/frbsdt1
HP : https://support.lenovo.com/fr/fr/
Lenovo : https://support.lenovo.com/fr/fr/
Acer : https://www.acer.com/ac/fr/FR/content/support
Asus : https://www.asus.com/fr/support/
ect...

Il y a coté des drivers une section BIOS ou UEFI et ta va trouver une mise à jour qui date de 2019 qu'il faut installer.

Certains PC récents (par exemple de marque HP) peuvent faire la mise à jour directement depuis le BIOS (il va se connecter à Internet, chercher la mise à jour et l'installer)

Mémoire flash de 8 Mo sur PC Dell :
(https://lafibre.info/images/cpu/201905_dell_mise_a_jour_uefi_1.jpg)

(https://lafibre.info/images/cpu/201905_dell_mise_a_jour_uefi_2.jpg)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 24 mai 2019 à 18:15:36
Il faut aller sur le site du fabricant de son PC (ou de sa carte mère si c'est un PC assemblé) et chercher le "support"  puis "Pilotes et téléchargement"...
Merci pour ta réponse: PC assemblé selon tes conseils avec carte mère MSI > j'y cours de ce pas.  (https://lafibre.info/images/smileys/@GregLand/ay.gif)

Edit: Pas de mise à jour sur le site (https://fr.msi.com/Motherboard/support/Z97-GAMING-5.html#down-bios) !  (https://lafibre.info/images/smileys/@GregLand/bh.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 24 mai 2019 à 19:44:49
Ah oui...

Ta carte mère a été conçue en 2014 et je vois que moins de deux ans après sa conception il n'y a plus de mise à jour du BIOS (dernière mise à jour février 2016), c'est très très court.
Même du matériel grand public, on a généralement au moins 4 ans de mises à jour.

Exemple : Mon PC est un Dell Inspiron 3847 conçue en 2013 (C'est un PC grnand public entrée de gamme à 400€), j'ai eu deux mises à jour de micro-code en 2018 : 21 février 2018 et 20 juin 2018. La firmware n'est pas sortie immédiatement, il a fallu attendre un a deux mois par rapport à des PC plus récents, mais le firmware est sorti. J’espère avoir celui pour MDS dans les prochaines semaines.
Je trouve ça étonnant que MSI ne fasse aucun suivit, surtout pour une carte mère plutôt sur le haut de gamme.

Je ne parle pas des serveurs où certaines marques font des firmwares pendant 8 ans (je pense au IBM System x x3550 M3 qui a reçu l'année dernière deux mises à jour du BIOS pour mettre à jour le microcode, alors qu'il date de 2011 voir même peut-être avant)

Cela signifie que tu n'as pas eu non plus les précédents correctifs avec les nombreuses failles qui sont sorties en 2018, cf Spectre et Meltdown: Grave problème de design des CPU Intel depuis 10ans (https://lafibre.info/serveurs/grave-probleme-de-design-des-cpu-intel-depuis-10ans/). Là aussi une mise à jour du micro-code est nécessaire pour Windows 7 pour être protégé.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 24 mai 2019 à 19:50:43
Merci pour ces précisions.  (https://lafibre.info/images/smileys/@GregLand/ad.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 24 mai 2019 à 21:11:18
Pour Windows 10, Microsoft va distribuer les microcodes. J'ai par contre un peu de mal a savoir si c'est via une mise à jour de l'UEFI/BIOS via Windows Update qui ne concernerait que certains PC de grande marque ou si c'est comme sous Linux, une distribution de microcodes qui sont installé a chaque démarrage dans le CPU (cette méthode permettant de traiter tous les PC / serveurs).
Sur mon Sandy Bridge-E (fin 2011), la dernière mise à jour du BIOS (beta) de ma carte mère (Asus P9X79) date de juillet 2014.
J'ai le microcode 0x713 (2018-01-26), donc Windows l'a mis à jour.
Sauf que le dernier est le 0x714 (2018-05-08), et il existe une mise à jour qui est censé le contenir : https://support.microsoft.com/fr-fr/help/4465065/kb4465065-intel-microcode-updates.

Selon https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf, il n'y a pas encore de microcode pour les failles MDS.

EDIT: j'ai téléchargé la mise à jour manuellement (http://www.catalog.update.microsoft.com/Search.aspx?q=4465065), windows10.0-kb4465065-v3-x64 datée du 15/02/2019.
=> microcode 0x714
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 24 mai 2019 à 21:39:11
Le microcode, quand c'est le système exploitation qui le met à jour, il me semble que c'est non persistant : il faut faire l'opération a chaque reboot

Mon Sandy Bridge plus vieux que le tien a eu sa mise à jour le jour du path thesday sous Linux.

Je pense que la seconde mis à jour de microcode envoyé il y a deux jours sous Ubuntu contient ton microcode.

(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_ok.png)

Comment tu fais pour voir le microcode sous Windows ?

CPU-Z ?
(https://lafibre.info/images/cpu/201905_cpu-z_intel_pentium_t2080_yonah.png)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 24 mai 2019 à 22:01:05
Il ne faut pas confondre les Sandy Bridge avec les Sandy Bridge-E (gamme HEDT sur socket 2011, dérivée des Xeon), c'est un i7-3930K.
Sur https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/master/releasenote, on voit bien SNB, mais pas SNB-E/Ex (aucun dérivé serveur de Sandy Bridge n'a donc été mis à jour pour les dernières failles, contrairement aux gammes plus récentes).

Dans CPU-Z : bouton tools en bas, Save report as .TXT
Il y a une ligne "Microcode Revision" dans le fichier généré.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 24 mai 2019 à 22:52:22
...Dans CPU-Z : bouton tools en bas, Save report as .TXT
Il y a une ligne "Microcode Revision" dans le fichier généré.
Pas dans la version 1.88 pour MSI !  (https://lafibre.info/images/smileys/@GregLand/bk.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: jack le 24 mai 2019 à 23:06:24
Le microcode, quand c'est le système exploitation qui le met à jour, il me semble que c'est non persistant : il faut faire l'opération a chaque reboot

En effet
De ma compréhension, il n'est pas possible de mettre à jour les CPU réellement
C'est à dire que le support de stockage physique n'est pas modifiable

Il y a donc deux methodes : soit le kernel applique un firmware, soit c'est le bios qui s'en charge

Linux permet de charger un microcode : l'initramfs est séparé en deux parties, la première contenant un seul fichier : le firmware, dans un chemin bien spécifique : early/kernel/x86/microcode/GenuineIntel.bin (lequel est hardcodé ici : https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/microcode/intel.c#L44)
On peut valider en extrayant un initramfs:
:~] unmkinitramfs /boot/initrd.img-4.19.0-5-amd64 .
:~] find early/ -type f
early/kernel/x86/microcode/GenuineIntel.bin

Ce qui est encore plus rigolo, c'est qu'on peut a priori charger des firmware n'importes quand, et pas seulement au chargement du kernel
Cependant, un firmware chargé tardivement ne pourra plus désactiver des fonctionnalités CPU sainement

:~] sudo iucode-tool -k GenuineIntel.bin -v
iucode-tool: processed 108 valid microcode(s), 108 signature(s), 108 unique signature(s)
iucode-tool: selected 108 microcode(s), 108 signature(s)
iucode-tool: Uploading selected microcodes to: /dev/cpu/microcode
iucode-tool: /dev/cpu/microcode: 108 microcode entries uploaded, 2411520 bytes

Je me demande pourquoi ce genre de fonctionnalité n'est pas disponible sous windows
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 24 mai 2019 à 23:28:58
Pas dans la version 1.88 pour MSI !  (https://lafibre.info/images/smileys/@GregLand/bk.gif)
Il suffit de prendre la version normale, pas celle avec le "skin" MSI.

Je me demande pourquoi ce genre de fonctionnalité n'est pas disponible sous windows
Le chargement après le démarrage ?
Pour les failles type Spectre/MDS, les contournements sont probablement activés au démarrage, et pas dynamiquement.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Marco POLO le 25 mai 2019 à 00:14:40
Il suffit de prendre la version normale, pas celle avec le "skin" MSI...
Je te remercie, mais je préfère conserver cette version, quoiqu'il y en ait une générique plus récente (1.89).  (https://lafibre.info/images/smileys/@GregLand/ab.gif)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 26 mai 2019 à 16:35:39
PC Dell en dual boot Ubuntu / Windows 10.
(https://lafibre.info/images/cpu/201905_cpu-z_intel_core_i3-6100_skylake.png)

Sous Ubuntu, sans la paquet intel-microcode, j'ai la révision 0xc6 du microcode et je suis vulnérable :
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_6.png)

Avec le paquet intel-microcode, j'ai la révision 0xcc et je suis "Mitigation" :
(https://lafibre.info/testdebit/ubuntu/201905_ubuntu_faille_mds_7.png)

Pour Windows 10, Microsoft ne me propose pas la mise à jour alors que je suis en Windows 10 64bits 1809 avec toutes les mises à jour, y compris celles de mai 2019.

Je vais sur le site de Dell pour avoir la mise à jour de l'UEFI, je vois qu'il y en a une en mars 2019, mais en fait elle ne semble pas intégrer les micro-code pour MDS :
(https://lafibre.info/images/cpu/201905_mise_a_jour_uefi_dell_1.png)

Effectivemnt aprés reboot, avec l'UEFI et Windows 10 à jour, je suis toujours sur la révision 0xC6 du microcode :
(https://lafibre.info/images/cpu/201905_cpu-z_intel_core_i3-6100_skylake_micocode.png)

Bref, je ne trouve pas de solution pour mitiger MDS sous Windows 10 avec un PC récent (Core i3 de 6ème génération)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 26 mai 2019 à 17:26:31
Bref, je ne trouve pas de solution pour mitiger MDS sous Windows 10 avec un PC récent (Core i3 de 6ème génération)[/size]
Selon le document Intel, il y a deux méthodes :
 - avoir le microcode, et appeler l'instruction VERW
 - exécuter une séquence de code qui écrit dans un buffer (variant selon la génération du CPU)
Je ne suis pas sûr de ce que fait le kernel de Windows, peut-être qu'ils ont aussi implèmenté la seconde méthode, dans ce cas la machine est protégée mais avec un coût plus important en performance.

https://support.microsoft.com/fr-fr/help/4093836/summary-of-intel-microcode-updates
La mise à jour avec le microcode 0xCC est disponible pour Windows 10 RTM, 1607, 1703 et 1709, mais pas les versions plus récentes !

Sur la page associée au CVE : https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv190013
Citer
Important Please note that at the release of this advisory, microcode updates provided by Microsoft for Intel processors are not available for the following versions of Windows. These microcode updates will be released at a later date. Microsoft recommends that customers running these versions of Windows install applicable Windows updates and obtain microcode updates for Intel-based devices from their OEM::

    Windows 10 Version 1803 for x64-based Systems
    Windows Server, version 1803 (Server Core Installation)
    Windows 10 Version 1809 for x64-based Systems
    Windows Server 2019
    Windows Server 2019 (Server Core installation)
Donc il faut attendre...

A noter que la 1903 a eu le patch kernel (cf la page du CVE), n'est pas dans la liste des versions qui n'ont pas la mise à jour de microcode, mais n'est la listée sur la page de la mise à jour des microcodes !
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 21 juin 2019 à 18:29:54
De nouveaux microcodes sont déployés :

(https://lafibre.info/testdebit/ubuntu/201906_ubuntu_mise_a_jour_faille_mds_1.png)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 13 août 2019 à 17:45:51
Ubuntu corrige CVE-2019-1125

Encore une de plus...

A Spectre gadget was found in the Linux kernel's implementation of system interrupts. An attacker with local access could use this information to reveal private data through a Spectre like side channel.


(https://lafibre.info/testdebit/ubuntu/201908_mise_a_jour_cve-2019-1125.png)
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: vivien le 13 août 2019 à 20:44:41
On me signale que des vulnérabilités ont été trouvées dans les kernel Linux, mais BitDefender n'ont semble-t-il réussi à proposer un PoC de cet exploit que sur Windows

cf livre blanc "Bypassing KPTI Using the Speculative Behavior of the SWAPGS Instruction" proposé par BitDefender. Ils y retracent l'historique de leur découverte.

Pour Windows, l'atténuation a été diffusée dans la patch tuesday d’août 2019.

AMD serait aussi impacté : The specific instruction of interest (SWAPGS) is only available on the x86-64 architecture, as such only x86-64 platform vendors (Intel and AMD) are known to be affected.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: hwti le 13 août 2019 à 21:03:10
AMD serait aussi impacté : The specific instruction of interest (SWAPGS) is only available on the x86-64 architecture, as such only x86-64 platform vendors (Intel and AMD) are known to be affected.
En partie, cf les sources de Linux.

https://github.com/torvalds/linux/blob/f4eb1423e43376bec578c5696635b074c8bd2035/arch/x86/kernel/cpu/common.c#L1068
Citer
    * Technically, swapgs isn't serializing on AMD (despite it previously
    * being documented as such in the APM).  But according to AMD, %gs is
    * updated non-speculatively, and the issuing of %gs-relative memory
    * operands will be blocked until the %gs update completes, which is
    * good enough for our purposes.

https://github.com/torvalds/linux/blob/f4eb1423e43376bec578c5696635b074c8bd2035/arch/x86/kernel/cpu/bugs.c#L340
Du coup les CPU AMD, comme les Atom, ont X86_FEATURE_FENCE_SWAPGS_KERNEL, mais pas X86_FEATURE_FENCE_SWAPGS_USER.
Les CPU Intel ayant KTPI activé dans le kernel (la protection pour Meltdown) sont également déjà indirectement protégés pour le passage user=>kernel.
Titre: MDS: Nouvelle vague de vulnérabilités d'exécution spéculative dans les CPU Intel
Posté par: Thornhill le 13 août 2019 à 21:23:12
Selon AMD :

https://www.amd.com/en/corporate/product-security (https://www.amd.com/en/corporate/product-security)

8/6/19

AMD is aware of new research claiming new speculative execution attacks that may allow access to privileged kernel data. Based on external and internal analysis, AMD believes it is not vulnerable to the SWAPGS variant attacks because AMD products are designed not to speculate on the new GS value following a speculative SWAPGS. For the attack that is not a SWAPGS variant, the mitigation is to implement our existing recommendations for Spectre variant 1.

Specific details by published description:

Description
   

AMD Recommendation

SWAPGS instruction speculation at CPL3 (Scenario 1) AMD believed not impacted

SWAPGS instruction speculation at CPL0 (Scenario 2, Variant 1) AMD believed not impacted

GS base value speculation (Scenario 2, Variant 2) AMD recommends implementing existing mitigations for Spectre variant 1