La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
NAS, serveurs et micro-serveurs => Discussion démarrée 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).
-
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.
-
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]
-
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...
-
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.
-
Cela concerne-t'il également les PCs sous Windows ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
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)
-
Merci: MàJ cumulative installée. (https://lafibre.info/images/smileys/@GregLand/ay.gif)
-
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)
-
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
-
"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)
-
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)
-
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)
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.
-
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)
-
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
-
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
-
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).
-
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)
-
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
-
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.
-
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)
-
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).
-
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
-
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
-
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.
-
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)
-
Et pour Win7 ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
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.
-
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
-
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)
-
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)
-
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)
-
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é.
-
Merci pour ces précisions. (https://lafibre.info/images/smileys/@GregLand/ad.gif)
-
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
-
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)
-
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é.
-
...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)
-
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
-
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.
-
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)
-
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)
-
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
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 !
-
De nouveaux microcodes sont déployés :
(https://lafibre.info/testdebit/ubuntu/201906_ubuntu_mise_a_jour_faille_mds_1.png)
-
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)
-
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.
-
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
* 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.
-
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
-
J’ai partagé des informations utiles pour suivre l’avancement de la parution des nouveaux microcodes et sur l’impact sur certaines performances causées par l’installation de ces mesures de prévention : https://lafibre.info/serveurs/mises-a-jour-des-microcodes-intel-et-amd/msg763239/#msg763239;
-
Nouvelle mise à jour des microcode Intel sous Ubuntu
Découverte en janvier 2020, la vulnérabilité CacheOut - également connue en tant que L1D Eviction Sampling - a évolué en SGAxe pour briser les extensions de sécurité des processeurs Intel permettant de faire tourner des applications dans des enclaves. Les processeurs Intel de 9e génération Coffee Lake Refresh sont notamment affectés.
(https://lafibre.info/images/materiel/202006_Intel_vulnerabilitee_SGAxe.webp)
- CVE-2020-0543 : Il a été découvert que le contenu de la mémoire précédemment stocké dans des registres spéciaux microarchitecturaux après les opérations de lecture RDRAND, RDSEED et SGX EGETKEY sur le client Intel et les processeurs Xeon E3 peut être brièvement exposé à des processus sur le même ou des cœurs de processeur différents. Un attaquant local pourrait l'utiliser pour exposer des informations sensibles.
- CVE-2020-0548 : Il a été découvert que sur certains processeurs Intel, des valeurs partielles de données précédemment lues à partir d'un registre vectoriel sur un noyau physique peuvent être propagées dans des parties inutilisées du tampon de stockage. Un attaquant local pourrait éventuellement l'utiliser pour exposer des informations sensibles.
- CVE-2020-0549 : Il a été découvert que sur certains processeurs Intel, les données de la ligne de cache de données L1 modifiée (L1D) peut être propagées dans un tampon de remplissage L1D inutilisé (non valide). Un attaquant local pourrait éventuellement l'utiliser pour exposer des informations sensibles.
(https://lafibre.info/testdebit/ubuntu/202006_ubuntu_mise_a_jour_microcode_intel.png)
Version 3.20200609.0ubuntu0.20.04.0 :
* SECURITY UPDATE: New upstream microcode datafile 2020-06-09
(includes updates from 2020-05-08 and 2020-05-20)
+ Updated Microcodes:
sig 0x000206d6, pf_mask 0x6d, 2020-03-04, rev 0x0621, size 18432
sig 0x000206d7, pf_mask 0x6d, 2020-03-24, rev 0x071a, size 19456
sig 0x000306c3, pf_mask 0x32, 2019-11-12, rev 0x0028, size 23552
sig 0x000306d4, pf_mask 0xc0, 2019-11-12, rev 0x002f, size 19456
sig 0x00040651, pf_mask 0x72, 2019-11-12, rev 0x0026, size 22528
sig 0x00040661, pf_mask 0x32, 2019-11-12, rev 0x001c, size 25600
sig 0x00040671, pf_mask 0x22, 2019-11-12, rev 0x0022, size 14336
sig 0x000406e3, pf_mask 0xc0, 2020-04-27, rev 0x00dc, size 104448
sig 0x00050653, pf_mask 0x97, 2020-04-24, rev 0x1000157, size 32768
sig 0x00050654, pf_mask 0xb7, 2020-04-24, rev 0x2006906, size 34816
sig 0x00050656, pf_mask 0xbf, 2020-04-23, rev 0x4002f01, size 52224
sig 0x00050657, pf_mask 0xbf, 2020-04-23, rev 0x5002f01, size 52224
sig 0x000506e3, pf_mask 0x36, 2020-04-27, rev 0x00dc, size 104448
sig 0x000706e5, pf_mask 0x80, 2020-03-12, rev 0x0078, size 107520
sig 0x000806e9, pf_mask 0x10, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806e9, pf_mask 0xc0, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806ea, pf_mask 0xc0, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806eb, pf_mask 0xd0, 2020-04-27, rev 0x00d6, size 103424
sig 0x000806ec, pf_mask 0x94, 2020-04-23, rev 0x00d6, size 103424
sig 0x000906e9, pf_mask 0x2a, 2020-04-23, rev 0x00d6, size 103424
sig 0x000906ea, pf_mask 0x22, 2020-04-27, rev 0x00d6, size 102400
sig 0x000906eb, pf_mask 0x02, 2020-04-23, rev 0x00d6, size 103424
sig 0x000906ec, pf_mask 0x22, 2020-04-27, rev 0x00d6, size 102400
sig 0x000906ed, pf_mask 0x22, 2020-04-23, rev 0x00d6, size 103424
- CVE-2020-0543 Special Register Buffer Data Sampling (SRBDS), INTEL-SA-00320
- CVE-2020-0548 Vector Register Sampling, INTEL-SA-00329
- CVE-2020-0549 L1D Eviction Sampling, INTEL-SA-00329
- Microcode fixes include update for 0x00050654 to address lockups on certain Skylake processors (LP: #1854764)
* Remaining changes:
- Ship tmpfiles.d snippet to attempt late loading of microcode during boot, in case early loading of microcode did not happen. Early microcode loading might not happen if booting without initramfs or a missbuilt one.
- debian/initramfs.hook: Do not override preset defaults from auto-exported conf snippets loaded by initramfs-tools.
-
Nouvelle mise à jour des microcode Intel sous Ubuntu
Version 3.20200609.0ubuntu0.20.04.0 :...
Salut Vivien,
Et pour Windows ? (https://lafibre.info/images/smileys/@GregLand/cs.gif)
-
Cela me rappelle une violente réaction de Linus Torvalds au sujet d'un patch venant d'AWS pour réparer une faille des CPU Intel, concernant la virtualisation, 'CPU Snoop Attack', qu'il a déclaré "plus que stupide" parce que ce patch serait susceptible de dégrader les performances pour toutes les applications :
Linus Torvalds rejects 'beyond stupid' AWS-made Linux patch for Intel CPU Snoop attack
Linux kernel developers debate a controversial patch to address potential leaks of secrets from a CPU's cores
...
But, as spotted by Phoronix, Torvalds believes the patch will allow applications that opt in to the patch to degrade CPU performance for other applications.
https://www.zdnet.com/article/linus-torvalds-rejects-stupid-aws-made-linux-patch-for-intel-cpu-snoop-attack/
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Blasts-L1d-Flushing