La Fibre
Datacenter et équipements réseaux => Équipements réseaux => 
NAS, serveurs et micro-serveurs => Discussion démarrée par: vivien le 13 novembre 2019 à 09:54:55
-
Encore des mises à jour du microcode pour les CPU Intel :
1/ CVE-2019-11135 : Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida, Giorgi Maisuradze, Moritz Lipp, Michael Schwarz, Daniel Gruss, and Jo Van Bulck ont découvert que les processeurs Intel utilisant TSX (Transactional Synchronization Extensions*) pouvaient exposer le contenu de la mémoire précédemment stockée dans des tampons microarchitecturaux à un processus malveillant s'exécutant sur le même cœur de processeur. Un attaquant local pourrait l'utiliser pour exposer des informations sensibles.
*TSX (Transactional Synchronization Extensions) est une extension de l’architecture du jeu d’instructions x86 qui ajoute la prise en charge de la mémoire transactionnelle matérielle, accélérant ainsi l’exécution de logiciels multi-threads par le biais de verrous. TSX peut fournir une exécution des applications environ 40% plus rapide dans des charges de travail spécifiques, et 4 à 5 fois plus de transactions de base de données par seconde.
J'ai par contre un peu de mal à comprendre quel CPU intègrent TSX.
2/ CVE-2019-11139 : Il a été découvert que certains processeurs Intel Xeon ne limitaient pas correctement l'accès à une interface de modulation de tension. Un attaquant disposant de privilèges locaux pourrait l'utiliser pour provoquer un déni de service (plantage du système).
(https://lafibre.info/testdebit/ubuntu/201911_Intel_microcode_CVE-2019-11135_CVE-2019-11139.png)
-
J'ai par contre un peu de mal à comprendre quel CPU intègrent TSX.
Initialement c'était dans Haswell, mais ça a été désactivé par microcode (ainsi que sur une partie des Broadwell) à cause de bugs.
J'ai l'impression que ça a déjà été désactivé sur au moins certains Skylake aussi à cause de bugs, et certains modèles n'ont pas la fonctionnalité (segmentation...).
Les mises à jour de microcode intègrent aussi potentiellement un contournement pour un bug, https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf (Skylake et plus récents), qui réduit les performances, parfois de façon notable : https://www.phoronix.com/scan.php?page=article&item=intel-jcc-microcode&num=1.
-
Pour ceux qui ont du mal à faire la conversion :
- Haswell => 4ème génération, gravés en 22nm : à partir de juin 2013
- Broadwell => 5ème génération, gravés en 14nm : à partir de septembre 2014
- Skylake => 6ème génération, gravés en 14nm : à partir de août 2015
- Kaby Lake => 7ème génération, gravés en 14nm : à partir du 4ème trimestre 2016
- Coffee Lake => 8ème génération, gravés en 14nm : à partir d'octobre 2017
-
Voici les dates des microcode pour quelques CPU :
Coffee Lake / 8ème génération : Nouveau microcode, daté d’août 2019
$ lscpu | grep modèle
Nom de modèle : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0xc6, date = 2019-08-14
[ 0.586612] microcode: sig=0x806ea, pf=0x80, revision=0xc6
[ 0.586934] microcode: Microcode Update Driver: v2.2.
Kaby Lake / 7ème génération : Nouveau microcode, daté d’août 2019
$ lscpu | grep modèle
Nom de modèle : Intel(R) Xeon(R) CPU E3-1240 v6 @ 3.70GHz
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0xc6, date = 2019-08-14
[ 1.533249] microcode: sig=0x906e9, pf=0x2, revision=0xc6
[ 1.539421] microcode: Microcode Update Driver: v2.2
Skylake / 6ème génération : Nouveau microcode, daté d’août 2019
$ lscpu | grep modèle
Nom de modèle : Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0xd4, date = 2019-08-14
[ 1.556020] microcode: sig=0x506e3, pf=0x2, revision=0xd4
[ 1.562203] microcode: Microcode Update Driver: v2.2.
Haswell / 4ème génération : non concerné
$ lscpu | grep modèle
Nom de modèle : Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x27, date = 2019-02-26
[ 0.320826] microcode: sig=0x306c3, pf=0x2, revision=0x27
[ 0.320862] microcode: Microcode Update Driver: v2.2.
Sandy Bridge / 2ème génération : non concerné
$ lscpu | grep modèle
Nom de modèle : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x2f, date = 2019-02-17
[ 0.902010] microcode: sig=0x206a7, pf=0x2, revision=0x2f
[ 0.902714] microcode: Microcode Update Driver: v2.2.
Sandy Bridge / 2ème génération : non concerné
$ lscpu | grep modèle
Nom de modèle : Intel(R) Xeon(R) CPU E5-1410 0 @ 2.80GHz
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x718, date = 2019-05-21
[ 1.641162] microcode: sig=0x206d7, pf=0x8, revision=0x718
[ 1.645712] microcode: Microcode Update Driver: v2.2.
-
Nouvelle fournée de mise à jour de microcode pour Intel et AMD.
Pour AMD on a uniquement l’information suivante :
- New microcode is available for AMD family 17h processors as of 2019-10-22.
- New microcode is published without a changelog, thus it is unknown what it fixes or regresses, yet it is recommeded to upgrade it. The 17h family microcode has been updated
A noter la différence de taille importante entre le paquet qui contient les microcode Intel (2,4 Mo) et celui qui contient ceux d'AMD (33 Ko) :
(https://lafibre.info/testdebit/ubuntu/201911_Intel_microcode_CVE-2019-11135_CVE-2019-11139_2.png)
-
Sur Intel non plus il y a aucune information sur les changements.
Il s'agit d'une deuxième mise à jour pour ces microcodes en quelques jours, alors qu'ils sont datés d'il y a plus d'un mois !
-
Je ne suis pas étonné de la date, il y a une phase de validation
incompréhensible incompressible.
Ce qui est dommage c'est l'absence d'information sur ce que cela change / corrige.
-
Je ne suis pas étonné de la date, il y a une phase de validation incompréhensible.
incompressible j'imagine (et donc compréhensible ;))
-
incompressible ;)
Tout comme la mise à jour 1909 (finalisé fin septembre) de Microsoft qui arrive en novembre.
-
Je ne suis pas étonné de la date, il y a une phase de validation incompréhensible incompressible.
Mais dans ce cas c'est étrange de ne pas avoir attendu 3 jours pour annoncer les bugs et publier directement les dernières versions.
Quant à la phase de validation, les microcodes 0xC6 d'aout étaient inclus dans une version insider de Windows début septembre (https://www.win-raid.com/t3355f47-Intel-AMD-VIA-amp-Freescale-CPU-Microcode-Repositories-Discussion-19.html), et certaines personnes avaient remarqué la baisse de performance (à cause du JCC Erratum) : https://www.win-raid.com/t5253f47-RE-Performance-issue-of-new-Intel-microcodes.html.
-
Pop corn, retour arrière pour AMD !
(https://lafibre.info/testdebit/ubuntu/201911_amd_microcode_1.png)
Le problème rencontré :
(https://lafibre.info/testdebit/ubuntu/201911_amd_microcode_2.png)
-
Pop corn, retour arrière pour Intel !
(https://lafibre.info/testdebit/ubuntu/201912_intel_microcode_1.png)
(https://lafibre.info/testdebit/ubuntu/201912_intel_microcode_2.png)
-
Voila pourquoi je ne mets JAMAIS à jour le microcode CPU. Opération beaucoup trop risquée sans support payant hors de prix.
Il sera remplacé, quand le CPU sera remplacé.
Quant aux attaques par canaux auxiliaires , je suis pas parano, ça va merci ;-)
-
[mode troll]
Moi, je ne met jamais mon système d’exploitation à jour.
Trop de risques de régressions.
[/mode troll]
Plus sérieusement, n'importe quel mise à jour, même celle de ton navigateur entraine des risques de régressions. Ces régressions touchent généralement un petit nombre de personnes (si cela touche beaucoup de personnes cela n'aurait pas passé les validations)
Ne pas mettre à jour son microcode, c'est s'exposer à des problèmes avec des logiciels récents qui s'attendent à avoir une version à jour du microcode :
Firefox 57 et versions plus récentes, sont connus pour planter occasionnellement avec des processeurs Broadwell-U équipés d'un ancien microcode d'une façon jamais rencontrée avec des versions plus récentes du microcode Broaswell-U.
Les mises à jour de microcode peuvent être chargées sur le processeur en utilisant le firmware (ordinairement appelé BIOS même sur des ordinateurs qui ont techniquement un firmware UEFI à la place du bon vieux BIOS) ou par le système d'exploitation. Les mises à jour de microcode ne se conservent pas après redémarrage, donc dans le cas d'un système à double amorçage, si la mise à jour du microcode n'est pas transmis via le BIOS, les deux systèmes d'exploitation devront fournir la mise à jour.
Pour permettre à Windows de charger le microcode mis à jour sur le processeur, assurez-vous que Windows Update est activé et paramétré de façon à installer les mises à jour.
Pour voir la microarchitecture du processeur et quelle révision du microcode est utilisée, lancez la commande reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 dans l'invite de commande Windows. (Vous pouvez ouvrir l'invite de commande en appuyant sur Windows + R, en saisissant cmd et en appuyant sur Entrée.) La ligne étiquetée « VendorIdentifier » indique le fabricant du processeur (GenuineIntel pour Intel ou AuthenticAMD pour AMD). La ligne étiquetée « Identifier » donne la microachitecture par trois nombres « Family », « Model » et « Stepping ». Ces derniers sont pertinents pour savoir si un bug de processeur en particulier pourrait s'appliquer au processeur de votre ordinateur. La ligne étiquetée « Update revision » montre la révision actuelle du microcode (pour cette microarchitecture spécifique) avec des zéros des deux côtés. Par exemple, Update Revision REG_BINARY 000000001E000000 signifie qu'il s'agit de la révision 1E (en hexadécimal). La ligne étiquetée « Previous Update Revision » indique la révision du microcode chargé depuis le BIOS.
Si le fabricant est GenuineIntel, la famille 6, le modèle 61 et le stepping 4, pour éviter les plantages avec Firefox 57 ou ultérieur, la révision du microcode doit être 1A ou plus élevée.
Source : Firefox (https://support.mozilla.org/fr/kb/mettre-a-jour-le-microcode-du-processeur)
Ce plantage de Firefox avec un vieux Microcode s'observe aussi bien sous Windows que sous Linux.
-
Ouai FF plante sur des vieilles versions, ok. J'ai jamais connu ça perso.
J'achète un CPU, mais je ne le mets pas à jour, car c'est trop risqué.
Je préfère le changer complètement, X années après.
Mettre à jour un OS, qui se met à planter après : c'est logiciel, ça se répare (et ça reste HYPER rare, je parle bien entendu de la famille UNIX).
Mettre à jour le microcode interne d'un CPU, c'est matériel. Si ca plante, tu prends la puce et tu la jette, ça a donc un coût non négligeable. (Ou en tout cas tu vas pas réparer ça en quelques heures).
Perso je mets à jour les logiciels, mais jamais le matériel.
Si le matériel plante, il faut changer le matériel. Si le logiciel plante, il faut simplement le réinstaller. C'est pas pareil en terme de temps et d'argent
-
Si le matériel plante, il faut changer le matériel. Si le logiciel plante, il faut simplement le réinstaller. C'est pas pareil en terme de temps et d'argent
Euh le microcode c'est logiciel... Ca s'appelle un firmware mais ça reste un logiciel :D
-
Je tiens à te rassurer, comme l'explique Firefox, "Les mises à jour de microcode ne se conservent pas après redémarrage", la mise à jour est appliqué après chaque reboot, soit par le BIOS/UEFI, soit par le système d'exploitation.
Si tu mets à jour ton BIOS/UEFI le système d'exploitation ne touchera pas au microcode.
Si ton microcode n'est pas à jour, aussi bien Linux que Windows va mettre à jour le microcode a chaque démarrage, cela se fait au tout début du boot. Il serait possible de modifier le microcode une fois le système d'exploitation complétement lancé, mais il me semble que c'est risqué.
Bref si tu utilises Windows, je vois mal comment tu refuses la mise à jour de ton microcode.
-
J'utilise Linux, et je ne mets pas à jour le microcode.
Comme ça au moins, pas de soucis :D
-
Un vrai rebelle 8)
-
Depuis l’apparition de Spectre, Meltdown, puis toutes leurs variantes, MDS (Microarchitectural Data Sampling), il faut savoir que l’application de ces nouveaux microcodes, sur des ordinateurs comportant des disques M.2 NVMe, fait chuter leurs performances d’environ 23 % (https://www.hardware.fr/focus/124/windows-10-meltdown-spectre-quel-impact-performances.html) voir plus (https://forum.hardware.fr/hfr/Hardware/hfr/meltdown-spectre-performances-sujet_1027888_1.htm#t10324402) (constat personnel à hauteur de 29 % sur un SSD NVMe 960 EVO 512 Go), ce qui n’est pas négligeable.
…
Bref si tu utilises Windows, je vois mal comment tu refuses la mise à jour de ton microcode.
Il suffit de laisser les mises à jour s’installer, puis d’effectuer deux lignes de commandes et de redémarrer, telles que Microsoft l’indique :
To disable mitigations for Intel® Transactional Synchronization Extensions (Intel® TSX) Transaction Asynchronous Abort vulnerability (CVE-2019-11135)
and Microarchitectural Data Sampling ( CVE-2018-11091 , CVE-2018-12126 , CVE-2018-12127 , CVE-2018-12130 )
along with Spectre [ CVE-2017-5753 & CVE-2017-5715 ] and Meltdown [ CVE-2017-5754 ] variants, including Speculative Store Bypass Disable (SSBD) [ CVE-2018-3639 ]
as well as L1 Terminal Fault (L1TF) [ CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646 ]:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /freg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /fRestart the computer for the changes to take effect.
Sources :
- éditions du client Windows : https://support.microsoft.com/fr-fr/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in
- éditions du système d’exploitation Windows Server : https://support.microsoft.com/fr-fr/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities
Pour surveiller si une nouvelle mise à jour de Windows 10 est publiée concernant la mise à jour du microcode, cette page les récapitule toutes : https://support.microsoft.com/fr-fr/help/4093836/summary-of-intel-microcode-updates. Après la publication d’une nouvelle mise à jour mettant à jour le microcode il est nécessaire de ré-appliquer les deux lignes de commandes indiquées par Microsoft.
Exemple, j’ai appliqué courant de l’année dernière les deux lignes de commandes, le dernier patch paru en janvier 2020 pour la dernière version de Windows 10 1909 est le KB4497165 (https://support.microsoft.com/fr-fr/help/4497165/kb4497165-intel-microcode-updates) conformément à la publications d’Intel (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html) concernant ses nouveaux microcodes (https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance.pdf), ainsi je dois ré-appliquer les deux lignes de commandes indiquées par Microsoft pour à nouveau désactiver le chargement du microcode au démarrage de Windows.
Pour visualiser ce dont on peut avoir besoin si l’on tient à installer uniquement le nécessaire, voir cette page : https://support.microsoft.com/fr-fr/help/4457951/windows-guidance-to-protect-against-speculative-execution-side-channel qui comporte cet organigramme assez explicite : (https://msegceporticoprodassets.blob.core.windows.net/asset-blobs/4472074_fr_1)
Bien sûr si l’on tient à faire les mises à jour du BIOS de sa carte mère, il est fort probable que le constructeur de celle-ci intègre aussi les nouvelles versions du microcode de son processeur, ce qui est compatible avec la démarche de désactivation logicielle indiquée ci-dessus dans la mesure où l’on ne souhaite pas voir, constater une chute des performances de son SSD NVMe. Ce qui signifie que faire les mises à jours de son BIOS n’est pas problématique surtout si l’on tient à corriger certains problèmes corrigés par les nouvelles versions du BIOS de sa carte mère.
-
J'ai l'impression qu'il y a deux types de mises à jour déployées par Microsoft :
- Mise à jour du microcode au lancement du système d’exploitation
- Binaire pour mettre à jour le BIOS/UEFI de certains PC portables de grande marque (dans ce cas là le micro-code est mis à jour dès que le PC s'allume, avant même le chargement du système d’exploitation)
Je signal un sujet plus récent sur le forum : MDS (Microarchitectural Data Sampling): Nouvelle vague de vulnérabilités autour de l'exécution spéculative dans les CPU Intel (https://lafibre.info/serveurs/mds/)
-
Nouveaux micocodes proposé sur tous les Ubuntu maintenus
Les multiples régressions qu'il y a eu lors de la mise à jour des microcode fait que Ubuntu prend plus de précautions et qu'il y a plusieurs mois de validation des microcodes.
La mise à jour disponible aujourd’hui corrige / atténue les 4 CVE suivantes :
- CVE 2020-8695 (https://nvd.nist.gov/vuln/detail/CVE-2020-8685) : La fonctionnalité Intel Running Average Power Limit (RAPL) de certains processeurs Intel a permis une attaque par canal latéral basée sur des mesures de consommation d'énergie. Un attaquant local pourrait éventuellement utiliser ceci pour exposer des informations sensibles.
- CVE 2020-8696 (https://nvd.nist.gov/vuln/detail/CVE-2020-8696) : Certains processeurs Intel ne supprimaient pas correctement les informations sensibles avant le stockage ou le transfert dans certaines situations.
- CVE 2020-8698 (https://nvd.nist.gov/vuln/detail/CVE-2020-8698) : Certains processeurs Intel n'isolaient pas correctement les ressources partagées dans certaines situations.
(https://lafibre.info/testdebit/ubuntu/202105_ubuntu_maj_microcode.png)
Petit historique :
11/07/2017 : intel-microcode 3.20151106.1 (microcode d'origine d'Ubuntu 16.04)
24/08/2017 : intel-microcode 3.20170707.1~ubuntu16.04.0 (correctif de la possible corruption de données avec Hyper-Threading activé)
12/01/2018 : intel-microcode 3.20180108.0~ubuntu16.04.2 (correctif de la faille Spectre)
23/01/2018 : intel-microcode 3.20180108.0+really20170707ubuntu16.04.1 (retour arrière cause instabilité)
31/03/2018 : intel-microcode 3.20180312.0~ubuntu16.04.1 (correctif de la faille Spectre)
08/05/2018 : intel-microcode 3.20180425.1~ubuntu0.16.04.1 (correctif de la faille Spectre)
28/08/2018 : intel-microcode 3.20180807a.0ubuntu0.16.04.1 (correctif de la faille "Speculative Store Bypass" CVE-2018-3639)
01/09/2018 : intel-microcode 3.20180807a.0ubuntu0.18.04.1 (Migration Ubuntu 18.04)
15/05/2019 : intel-microcode 3.20190514.0ubuntu0.18.04.2 (correctif de la faille MDS)
21/06/2019 : intel-microcode 3.20190618.0ubuntu0.18.04.1 (correctif de la faille MDS)
13/11/2019 : intel-microcode 3.20191112-0ubuntu0.18.04.2 (correctif de la faille TSX + modulation de tension)
04/12/2019 : intel-microcode 3.20191115.1ubuntu0.18.04.2 (retour arrière cause régression sur processeur Skylake)
10/06/2020 : intel-microcode 3.20200609.0ubuntu0.18.04.0
11/06/2020 : intel-microcode 3.20200609.0ubuntu0.18.04.1
29/09/2020 : intel-microcode 3.20200609.0ubuntu0.20.04.2 (Migration Ubuntu 20.04 proposée depuis le 29/09)
12/11/2020 : intel-microcode 3.20201110.0ubuntu0.20.04.1
13/11/2020 : intel-microcode 3.20201110.0ubuntu0.20.04.2 (retour arrière cause régression)
17/05/2021 : intel-microcode 3.20210216.0ubuntu0.20.04.1 (CVE 2020-0543, CVE 2020-8695, CVE 2020-8696 et CVE 2020-8698).