Reprise du message précédent :
en effet,
les 3e gen sont dans les 'legacy' alors que les 4e gen sont encore dans la page principale
https://ark.intel.com/#@PanelLabel122139
mais les détails ne sont pas clairs:
mon 4670k est marqué 'End of Life' bien que encore < 5 ans:
https://ark.intel.com/products/seri [...] Processors
comme le 3770k
https://ark.intel.com/products/6552 [...] o-3_80-GHz

Et Intel n offre que 3 ans de garantie sur ses CPU, pas 5:
https://www.intel.com/content/www/u [...] ssors.html
(en tous cas sur les 6eme gen)

Néanmoins, Intel a publié mi novembre une update pour Linux des micro codes de ses CPU, le plus ancien que j ai repéré dans la liste étant le P3 450 qui a 19 ans:
https://downloadcenter.intel.com/do [...] duct=27536
-> est ce l update pour fixer les failles meltdown/spectre?

Qui sous Linux a t il tenté d appliquer cette update? Et sur un vieux système style p3, p4 ou core2duo?

 
Si je comprends bien, pour les processeurs antérieurs, la mise à jour du micro-code ne serait pas nécessaire en complément du patch windows? Dans le cas contraire, tous les CPU/PC pré-haswell resteront vulnérables, donc bons pour le recyclage...

Je remets ici le test fait avec un core i7-3770:
 
sudo ./spectre-meltdown-checker.sh  
 
Spectre and Meltdown mitigation detection tool v0.19
 
Checking for vulnerabilities against live running kernel Linux 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64
Will use vmlinux image /boot/vmlinuz-4.9.0-5-amd64
Will use kconfig /boot/config-4.9.0-5-amd64
Will use System.map file /proc/kallsyms
 
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO  (only 31 opcodes found, should be >= 70)
> STATUS:  VULNERABLE  (heuristic to be improved when official patches become available)
 
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO  
*   Kernel support for IBRS:  NO  
*   IBRS enabled for Kernel space:  NO  
*   IBRS enabled for User space:  NO  
* Mitigation 2
*   Kernel compiled with retpoline option:  NO  
*   Kernel compiled with a retpoline-aware compiler:  NO  
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES  
* PTI enabled and active:  YES  
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

 
La vache    
 

 
Certainement, je ne les vois pas publier des updates de microcodes sur 19 ans de CPU pour autre chose !

tu peux essayer d appliquer l update des microcode de novembre, mais à tes risques et périls!
y a t il des experts Linux dans la salle pour dire si il est judicieux de vouloir appliquer les micro code Intel manuellement, comme suggéré par ex sur cet article?  https://www.pcsuggest.com/update-cp [...] -in-linux/
(via un sudo apt-get install intel-ucode )

 
 
 
à moins qu il ne s agisse que des descriptifs des CPU pour le noyau Linux? Les updates précédantes listaient aussi tous les CPU...

Pour Linux plus d'infos ici :
https://access.redhat.com/articles/3311301
 

 
Par contre le micocode AMD ne concerne que les Epyc (800F12 only)
 
 "AMD Did NOT Disable Branch Prediction With A Zen Microcode Update"
https://www.phoronix.com/scan.php?p [...] tion-Still
 
https://bugs.debian.org/cgi-bin/bug [...] bug=886382
https://bugs.gentoo.org/643476

Les 3 ans, c'est pour la garantie matérielle; pour la partie logicielle (microcode), c'est beaucoup plus.
De toute façon, Intel ne peut pas se permettre de laisser une telle faille sur ses processeurs.
Il doit y avoir encore beaucoup de CPU >5ans en fonctionnement; donc un grand nombre de PC succeptibles d'être attaqués...
L'image de marque d'Intel en prendrait un sacré coup...
 

 
Sous Linux, le firmware CPU est mis-à-jour automatiquement lors du reboot;
Actuellement, sur Debian 9, la faille meltdown est corrigée avec la mise-à-jour du 4 janvier (Kernel 4.9.0-5)
Par contre le microcode des CPU Intel date de 07.07.2017; la MAJ chez Debian est assez longue (les paquets doivent être éprouvés)
Il existe des microcodes plus récents (unstable): intel-microcode_3.20171117.1 et intel-microcode_3.20171215.1
Voir ici : http://ftp.fr.debian.org/debian/po [...] microcode/
 
Changelog du microcode 3.20171215.1 (unstable):  
Binary: intel-microcode
Architecture: source amd64
Version: 3.20171215.1
Distribution: unstable
Urgency: high
* Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
* Implements IBRS and IBPB support via new MSR (Spectre variant 2 mitigation, indirect branches).  Support is exposed through cpuid(7).EDX.
* LFENCE terminates all previous instructions (Spectre variant 2 mitigation, conditional branches).
 
complet ici : https://tracker.debian.org/news/899110

Ces microcodes sont en unstable...
Je préfère attendre qu'ils passent en stable... pas envie de servir de béta-testeur avec mon PC de travail
 
Par contre, la distribution d'Intel Clear Linux 20240 (Linux 4.14.12) a été patchée avec  KPTI page table isolation & Retpoline support  
Les benchs montrent que l'écart avec et sans les correctifs sont limités !
 
Benchs sur Phoronix:  
https://www.phoronix.com/scan.php?p [...] line&num=1

Toutes mes machines sont sur Sid aka unstable depuis une décennie ... ;-)
Bah si tu préfères être vulnérable :
https://security-tracker.debian.org [...] -2017-5715

Sans tomber dans la théorie du complot, je prends les tests phoronix avec des pincettes (le gars semble terriblement sensible aux espèces sonnantes et trébuchantes)

Clair ! d'un coté c'est son gagne pain..

 
 
Ah OK, c'est un fichier pour tous les CPU Intel en fait, rien ne dit qu'ils aient tous été màj...

@scorpio810
C'est sûr, mais ça n'excuse rien. cracher sur un (cpu, cg, etc.) tel jour et raconter exactement l'inverse le lendemain, ça n'est pas un journaliste fiable.
Concernant le microcode Intel, je pense vraiment qu'il faut l'éviter (palliatif vraiment pourri pour une faille pas encore exploitée: retpoline est clairement une meilleure solution... ...pour les machines Intel   )

Si ton proc est antérieur à la génération Haswell (-E -EP ?), il uploadera rien dans ton microprocesseur, pour le pach/microcode déployé ces derniers jours par Intel
 
L'outil d'upload va d'abord vérifier le CPUID de ton processeur (pour savoir quel type/modèle de proc c'est) et ensuite va vérifier dans le répertoire/le fichier qui contient le/les MAJ de microcode si un de ceux ci correspond au CPUID de ton proc
Si oui, il envoie le microcode correspondant à ton proc
Si non, il ne fait rien
 
Au final, il te dit ce qu'il a fait ou pas fait

https://www.ovh.com/fr/blog/failles [...] ic-averti/

Mon antivirus avira est hs depuis la maj Windows. Drôle de façon de sécuriser la machine.

   
une explication claire et détaillée avec des exemples pour completer les articles de Guillaume ici sur hfr!

 
C'est quoi la mise à jour de Windows car j'ai aussi AVIRA ANTIVIRUS PRO !!!???

le correctif cumulatif de sécurité de windows de ce mois ci kb4056895
l'antivirus a quand même l'air de bosser mais je ne peux pas l'ouvrir et il n'apparait pas dans la barre des taches

Toujours rien pour Windows 7, ils ont retardé les màj ?

edit: trouvé:
2018-01 Correctif cumulatif mensuel de qualité pour Windows 7 pour les systèmes basés sur x64 (KB4056894)
2018-01 Correctif cumulatif mensuel de qualité pour Windows 7 pour les systèmes basés sur x86 (KB4056894)

A éviter sur les sytèmes avec vieux CPU AMD (type Athlon 64), ça fout en l'air le système.

Plus d'infos: https://support.microsoft.com/en-us [...] -kb4056894

Si vous n'avez pas d'antivirus compatible (ou si vous n'en avez pas du tout, ou seulement Defender), les màj via Windows Update sont bloquées.

Il faut alors créer cette clé (collez le texte dans un fichier texte et enregistrez le au format reg).

(Ne le faites pas si vous avez un antivirus non compatible).

Si les mises à jour sous Windows 7 sont sorties le mien est incompatible car j’ai que la mise à jour de framework kb405553
En faite la kB4056894 est sortie hier soir

Attention, ça c'est la mise à jour cumulative mensuelle avec tout et n'importe quoi à l'intérieur. Pour mettre uniquement le patch pour Meltdown il faut chercher la mise à jour KB4056897 pour windows 7.    

 
Oui, c'est celle proposée sur Windows Update quoi    
 
Je l'ai faite (via WU après avoir ajouté la clé mentionnée) et mon PC n'a pas pris feu    
 
J'ai testé vite fait CPU et RAM avec AIDA64, pas de différence de perfs avant/après.

Ivy Bridge-E est sorti il y a moins de 5 ans, contrairement à Ivy Bridge.
Pas sûr qu'il reçoive une mise à jour du microcode pour autant.

 
J'ai fait quelques tests sur mon pc portable avant/après si ça intéresse
 

Benchmark d'encodage qu'on trouve ici : https://forum.hardware.fr/hfr/Hardw [...] 8463_1.htm :
 
 
 
Avant correctif :
 

 
Après correctif :
 

 
 
 
PCMARK10 :
 

 
x264 benchmark v5.0.1 :
 

 
cinebench R15 :
 

 
 
cinebench R11 :
 

 
bench cpu-z :

 
bench de la ram :
 

crystaldiskmark sur hdd :

 
crystaldiskmark sur ramdisk :

https://www.theverge.com/2018/1/9/1 [...] c-slowdown
 
Essayez surtout de mesurer la latence avant/après, chez moi c'était catastrophique, des pointes à 4 secondes j'ai désinstallé le patch fissa!
 
Vous pouvez tester avec DPC Latency Checker.

 
Actuellement, on a :
-microcode.dat qui date de novembre
-10 firmware additionnels de décembre pour les archis suivants :
3x06C3 => Haswell LGA1150
3x06D4 => Broadwell mobile
3x06F2 => Haswell-E LGA2011
4x0651 => Haswell-ULT mobile
4x06E3 => Skylake mobile
4x06F1 => Broadwell-E LGA2011
5x0654 => Skylake-W/S
5x06C9 => Apollo-lake/Goldmont
8x06E9 => KabyLake mobile
9x06E9 => Kabylake LGA1151
 
On parle d'arch OEL, pas de CPU.

Si l'envie t'en dit, tu peux essayer de patcher toi même ton UEFI avec ces binaires
Il te faut UEFItool:
https://github.com/LongSoft/UEFITool

Et trouver l'adresse où se trouve le ucode. (C'est assez simple avec l’entête)
Par contre il faut idéalement que la taille du ucode soit la même sinon il faut modifier la table d'adresse.
Les noms des ucodes dans le package sont: family-model-stepping. A faire donc correspondre au CPU présent sur la CM.

Il y a eu une nouvelle version d'UBU hier. Elle doit contenir les nouveaux ucodes également (cela doit être les mêmes que ceux du package Linux, ils sont juste renommés normalement)  :
https://www.win-raid.com/t154f16-To [...] t-UBU.html

Pour mon Haswell-E, dans le package Linux, le ucode est en version 0x3A d’après le header du fichier. C'est le même numéro de version que celui que j'utilise actuellement dans mon bios custom et qui date de début 2017 (Asus se limitant au 0x38 dans ses derniers bios)
Il faut que je compare les deux fichiers pour voir s'ils sont identiques...

Sur le blog de Microsoft :  
https://cloudblogs.microsoft.com/mi [...] s-systems/
 
Dans la section performance, ils annoncent des résultats nuancés selon la version de l'OS et du processeur.
 
 TLDR :  
- Haswell (ou -)   + W10 -> Léger ralentissement
- Skylake(ou +)  + W10 -> Aucune différence.
- Serveur -> Impact notable.

C'est du pain béni pour crosoft : pousser les entreprises a passer sur w10 et ou remplacer le hardware ...

With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance.
With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.

bizarre cette affaire, en quoi le patch donnerait des perfs différentes sous Win10 vs Win7/8 ??
Ou MS a t il fait le patch différemment pour ralentir délibéremment les anciens OS ?

Il l'expliquent comme ça dans leur article :
 

https://packages.qa.debian.org/a/am [...] 0416Z.html
Binary: amd64-microcode
Architecture: source amd64
Version: 3.20171205.1
Changes:
 amd64-microcode (3.20171205.1) unstable; urgency=high
 .
   * New microcode updates (closes: #886382):
     sig 0x00800f12, patch id 0x08001213, 2017-12-05
     Thanks to SuSE for distributing these ahead of AMD's official release!
   * Add IBPB support for family 17h AMD processors (CVE-2017-5715)
   * README: describe source for faml17h microcode update
   * Upload to unstable to match IBPB microcode support on Intel in Debian
     unstable.
   * WARNING: requires at least kernel 4.15, 4.14.13, 4.9.76, 4.4.111 (or a
     backport of commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf
     "x86/microcode/AMD: Add support for fam17h microcode loading" ) otherwise
     it will not be applied to the processor.

Edit : c'est bien ce que je pensais ce n'est que pour les Epyc, pas vu de changement sur la version du microcode sur mon r7 :
oops kernel 4.14.13.. reste plus qu'a le compiler..

@scorpio810. Bon, moi qui pensais que Ryzen n'était pas vulnérable à Spectre variante 2 :-/
 
Même chose chez RedHat, le microcode est là :

... mais pas encore le kernel qui va bien.
 
L'article RedHat:
https://access.redhat.com/articles/3311301

 
Edit: à noter qu'il n'y a pas de mise à jour microcode pour intel chez RedHat (les derniers datent du 22 novembre)

@imarune : le microcode amd ne concerne que les AMD Epyc (800f12), les Ryzen c'est 800f11 et ne sont donc pas concernés, je viens de le vérifier avec un 4.14.13 tout juste compilé et le dernier amd64-microcode.

AMHA,je pense qu'ils prennent leurs précautions pour ne pas prendre de risques avec les gros clients "cloud, serveurs, etc" en Epyc, de toute manière Intel a fait de même .. mais sur tout les cpu ..

"This new firmware disables branch prediction on AMD family 17h processor
to mitigate a attack on the branch predictor that could lead to
information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715)."

désactiver complétement la prédiction de branche devrait avoir des conséquences sensibles sur les perfs des Epyc!
Ou est ce une stratégie pour vendre les CPU avec plus de cores ?

Ça pourrait être aussi un gros cadeau fait a Intel, va savoir ... pour que les puces serveurs soient sur le même pied d’égalité....
De toute façon c'est noël pour eux ... les gros clients vont devoir réinvestir largement pour compenser les pertes de perfs ..

Ou as tu trouvé cette info  (800f12/f11)? /DTC proof

Hum, je ne pense pas qu'AMD soit prêt à faire des cadeaux à Intel. Amha, c'est qu'ils ne savent pas réellement si leurs procs sont vulnérables à Spectre 2 (ou à une de ses futures variantes), et (à raison) se protègent préventivement?
 
Edit: c'est vraiment chiant que Ryzen soit impacté par Spectre 2, vu que cette mise à jour microcode tue les performances  

@imarune : https://twitter.com/TheRegister/sta [...] 0320878592

Pas d'ivy bridge ?