Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2620 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2  3  4
Auteur Sujet :

[HFR] Actu : Microcode Intel beta la semaine prochaine

n°10315094
cpagrave
Posté le 21-01-2018 à 16:18:40  profilanswer
0Votes positifs
 

Reprise du message précédent :

lecbee a écrit :


BIOS/UEFI = carte mère (dans l'EEPROM)

 


 

C_Wiz précise que ça ne survit pas à un cold boot, j'en déduis que c'est stocké dans une mémoire volatile.


Message édité par cpagrave le 21-01-2018 à 16:18:59
mood
Publicité
Posté le 21-01-2018 à 16:18:40  profilanswer
 

n°10315757
C_Wiz
Profil : Equipe HardWare.fr
Posté le 22-01-2018 à 22:36:08  profilanswer
2Votes positifs
 

Pour info, Intel dit avoir identifié la cause des "redémarrages" (il ne faut pas dire plantages visiblement) observés sur certaines configurations avec son dernier BIOS. Un BIOS beta a été livré aux gros clients (comprendre AWS, Google et Azure) et est en cours de test. Aucune info sur la version finale donc on va attendre encore, Intel ne s'engage sur rien : https://newsroom.intel.com/news/roo [...] -partners/  
 
Le gros changement est qu'Intel recommande aux utilisateurs qui ne l'auraient pas fait de ne pas mettre à jour leur BIOS en attendant (ce qu'on vous suggérait un peu plus tôt dans ce thread).
 
L'autre chose bizarre est qu'une fois de plus Intel ne parle que de Haswell et Broadwell ce qui contredit leur communiqué de la semaine dernière qui admettait que les plantages touchaient d'autres plateformes...


Message édité par C_Wiz le 22-01-2018 à 22:45:23
n°10315765
Ouiche
Posté le 22-01-2018 à 23:06:07  profilanswer
0Votes positifs
 

[...]as they may introduce higher than expected reboots[...].
 
Je garde cette formulation :D
 
"Le problème touchant cette série de moteurs qui pourrait entraîner un nombre d'explosions plus élevé que prévu".


Message édité par Ouiche le 22-01-2018 à 23:07:48
n°10315786
C_Wiz
Profil : Equipe HardWare.fr
Posté le 22-01-2018 à 23:43:58  profilanswer
1Votes positifs
 

On voit bien la pate du département légal qui demande de TOUT minimiser :D
 
Je ne suis pas juriste mais je pense que c'est peine perdue et que ces minimisations outrancières risquent au contraire de se retourner contre Intel dans le système judiciaire bien particulier qu'est le système américain. Une fois de plus les avocats ne vont pas chomer...
 
A la décharge d'Intel, le vent de panique est similaire chez les concurrents (mais Intel est significativement plus exposé).


Message édité par C_Wiz le 22-01-2018 à 23:44:45
n°10315839
lonely
Posté le 23-01-2018 à 07:06:31  profilanswer
1Votes positifs
 

Ce serait sympa qu'Intel arrive à fixer le bug.  
Depuis, une semaine mon PC (6700k, Asus Z170-Deluxe) démarre aléatoirement (parfois pas du tout avec des reboots, parfois de façon incomplète, quelques fois il arrive à marcher heureusement) et il n'arrive plus à s'arrêter correctement.  
Je suis à jour sur tous les fixes (Windows 10 Pro, BIOS Asus mis à jour (3703), ...). Cela a commencé avec la mise à jour Windows (qui a rendu mon PC instable) puis le BIOS qu'il n'a pas du tout aimé.


Message édité par lonely le 23-01-2018 à 07:08:05
n°10315877
oufouf84
Posté le 23-01-2018 à 08:53:10  profilanswer
0Votes positifs
 

C_Wiz a écrit :


Garder Windows Update (ou autre) actif et attendre les prochaines mises à jour de BIOS.


 
donc avec une Z97 asus c'est foutue en gros :/ vue que le suivie chez eux est inexistant :(
https://reho.st/thumb/self/a26170d751fd57af62918cbf494cd26bd368ec5d.png
 


Message édité par oufouf84 le 23-01-2018 à 08:56:27
n°10315890
SirGallaha​d
What's your favorite color ?
Posté le 23-01-2018 à 09:28:35  profilanswer
0Votes positifs
 

J'ai la même chose que toi avec un magnifique : "SLOWER" dans performance :p
Je pense que la maj pour les Z77 va encore mettre un certain temps a arriver.
 
Cela dit il m'annonce que le PC est plus lent, mais n'ayant pas toucher mes VM ou SQL Server depuis 2 semaines, Avec uniquement du jeu, je n'ai pas remarquer de différence notable

n°10315978
scorpio810
Posté le 23-01-2018 à 11:11:24  profilanswer
0Votes positifs
 

intel-microcode (3.20180108.1+really20171117.1) unstable; urgency=critical
 
  * Revert to release 20171117, as per Intel instructions issued to
    the public in 2018-01-22 (closes: #886998)
  * This effectively removes IBRS/IBPB/STIPB microcode support for
    Spectre variant 2 mitigation.

n°10316092
luxy
le futur c'est ZEN et hydrogen
Posté le 23-01-2018 à 13:49:10  profilanswer
0Votes positifs
 

merci pour les infos

n°10316173
woxxi
Posté le 23-01-2018 à 15:36:26  profilanswer
0Votes positifs
 

SirGallahad a écrit :


Je pense que la maj pour les Z77 va encore mettre un certain temps a arriver.


 
Si elle arrive un jour et il faut aussi que le fabricant de ta carte mère fasse l'effort de mettre à jour le bios d'une CM vieille de presque 6 ans.
Pour l'instant chez Asus c'est jusqu'au X99 au plus loin (août 2014 quand même).

mood
Publicité
Posté le 23-01-2018 à 15:36:26  profilanswer
 

n°10316175
C_Wiz
Profil : Equipe HardWare.fr
Posté le 23-01-2018 à 15:39:50  profilanswer
0Votes positifs
 

oufouf84 a écrit :


donc avec une Z97 asus c'est foutue en gros :/  


Pas forcément, Windows livrera certainement le microcode aussi via une update un jour.

n°10316196
Nono0000
Posté le 23-01-2018 à 16:01:23  profilanswer
0Votes positifs
 

woxxi a écrit :

 

Si elle arrive un jour et il faut aussi que le fabricant de ta carte mère fasse l'effort de mettre à jour le bios d'une CM vieille de presque 6 ans.
Pour l'instant chez Asus c'est jusqu'au X99 au plus loin (août 2014 quand même).

 

Mouais en X99 c'est juste deux CM... mais bon tout est en "hold" pour le moment je suppose...

 

Après pour ceux qui ont un système de récupération de bios corrompu (flashback, crashfree ou autre) ils peuvent essayer de mettre à jour leur uCode eux-mêmes sans réel risque de briquer la CM.
Avec UBU, par exemple, c'est la manière forte mais c'est très simple d'utilisation.
Pour les autres, il vaut mieux être sûr de son coup... :/


Message édité par Nono0000 le 23-01-2018 à 16:02:49

---------------
CPU: 6950X 4.3Ghz (Uncore: 3.7Ghz) WC HM -- Mem: 4x8Go 3200Mhz 14-16-17-32-1T -- Mobo: Asus X99 Deluxe -- GPU: 4080 (GPU: 3015Mhz, VRAM: 12200Mhz) -- Carte Son: X-Fi Titanium Fatal1ty Professional -- SSD: M.2 PCIE XP941 -- Ecran: DELL AW3423DW QD-OLED
n°10316200
manusfreed​om
''Le reste est a venir''
Posté le 23-01-2018 à 16:05:06  profilanswer
0Votes positifs
 
n°10316211
Nono0000
Posté le 23-01-2018 à 16:26:17  profilanswer
0Votes positifs
 


 
Malheureusement, le driver de VMware se charge trop tard visiblement (après la détection par l'OS de la présence ou non du nouveau uCode) ce qui fait que Windows n'active pas les contre-mesures SW pour spectre:
"It is consensus achieved here in Guru3d forums that VMware driver method loads microcode at too late stage when kernel is already loaded and initialized. And kernel being initialized without new microcode doesn`t turn Spectre mitigation On."


---------------
CPU: 6950X 4.3Ghz (Uncore: 3.7Ghz) WC HM -- Mem: 4x8Go 3200Mhz 14-16-17-32-1T -- Mobo: Asus X99 Deluxe -- GPU: 4080 (GPU: 3015Mhz, VRAM: 12200Mhz) -- Carte Son: X-Fi Titanium Fatal1ty Professional -- SSD: M.2 PCIE XP941 -- Ecran: DELL AW3423DW QD-OLED
n°10316212
regis183
Posté le 23-01-2018 à 16:26:45  profilanswer
0Votes positifs
 

guigotech a écrit :

Désolé de vous déranger les gars !
 
Mais j'ai une petite question de néophyte.
Après avoir lu pas mal d'articles sur le sujet, j'ai comprit que spectre et meltdown c'est pas cool.
Mais concrètement pour un utilisateur moyen comme moi, des jeux, du surf, lire des vidéos.
Ai-je vraiment un risque de me faire hack via ces failles ?


Houlà t'as une activité à risque toi.
M'étonnerais ps que la CIA soit en train de fromenter une extorsion de tes données les plus confidentielles. Fait gaffe quand tu marches dans la rue si tu vois une ombre qui te suis ou si ta bière à un gout bizarre.
Enfin tu risques surtout d'avoir des plantages système si tu installes des patchs bêta.

n°10316260
Mki2268
Posté le 23-01-2018 à 17:31:24  profilanswer
2Votes positifs
 

Linus Torvalds (créateur du Kernel Linux) a fortement critiqué les patchs d'Intel: "As it is, the patches  are COMPLETE AND UTTER GARBAGE"
Il dit même que du (mauvais) code sert à masquer les problèmes dans les benchmarks...
 
Son post (en anglais):
https://lkml.org/lkml/2018/1/21/192


Message édité par Mki2268 le 23-01-2018 à 17:31:49
n°10316288
obyoneone
Posté le 23-01-2018 à 18:32:00  profilanswer
1Votes positifs
 

un peu comme VW...

n°10316312
C_Wiz
Profil : Equipe HardWare.fr
Posté le 23-01-2018 à 19:11:20  profilanswer
1Votes positifs
 

Mki2268 a écrit :

Linus Torvalds (créateur du Kernel Linux) a fortement critiqué les patchs d'Intel: "As it is, the patches  are COMPLETE AND UTTER GARBAGE"
Il dit même que du (mauvais) code sert à masquer les problèmes dans les benchmarks...
 
Son post (en anglais):
https://lkml.org/lkml/2018/1/21/192


Au delà de son langage coloré et du fait qu'il a mélangé un peu des trucs, le fond du débat c'est que Intel pousse à ce que le patch Spectre soit Opt-in sous Linux, parce que l'impact sur les perfs est important.  
 
Il n'a pas tort ;) Les patchs ne sont pas acceptés pour l'instant de toute façon. Pour l'instant seul retpoline est mis en place au niveau du kernel, ce message parle des mitigations IBRS (celles qui reposent sur la maj microcode) qui sont en court de développement.  
 
Le consensus est que retpoline n'est pas suffisant dans pas mal de cas, et particulièrement sur Skylake+ chez Intel ou IBRS sera probablement obligatoire.

n°10316327
myxpc95g5
Posté le 23-01-2018 à 19:32:22  profilanswer
1Votes positifs
 

Avec mon antique Bloomfield, je suis exclu d'une mise à jour de firmware  :(  
Le microcode demeure à la version 18 depuis des lustres.
http://blog.cyring.free.fr/images/CoreFreq_Firmware.png
 
A choisir entre performance et sécurités, je prends le risque de privilégier les Perfs  :sol:  
http://blog.cyring.free.fr/images/CoreFreq_TurboMax.png

n°10316361
Nono0000
Posté le 23-01-2018 à 20:29:51  profilanswer
0Votes positifs
 

myxpc95g5 a écrit :

Avec mon antique Bloomfield, je suis exclu d'une mise à jour de firmware  :(  
Le microcode demeure à la version 18 depuis des lustres.
http://blog.cyring.free.fr/images/ [...] rmware.png
 
A choisir entre performance et sécurités, je prends le risque de privilégier les Perfs  :sol:  
http://blog.cyring.free.fr/images/ [...] rboMax.png


 
C'est étonnant car si je regarde dans le package Intel pour Linux, il y a un microcode 0x19 pour ton CPU... mais il date du... 21/06/2013  :D


---------------
CPU: 6950X 4.3Ghz (Uncore: 3.7Ghz) WC HM -- Mem: 4x8Go 3200Mhz 14-16-17-32-1T -- Mobo: Asus X99 Deluxe -- GPU: 4080 (GPU: 3015Mhz, VRAM: 12200Mhz) -- Carte Son: X-Fi Titanium Fatal1ty Professional -- SSD: M.2 PCIE XP941 -- Ecran: DELL AW3423DW QD-OLED
n°10316389
myxpc95g5
Posté le 23-01-2018 à 21:02:00  profilanswer
0Votes positifs
 

Nono0000 a écrit :


 
C'est étonnant car si je regarde dans le package Intel pour Linux, il y a un microcode 0x19 pour ton CPU... mais il date du... 21/06/2013  :D


 
Etrange ! aussi bien dans /proc/cpuinfo ou via cpuid, je n'ai pas mieux que 18 (12h)
 
Et ce, avec le dernier package microcode en date 20180108 sur ArchLinux 4.14.14
 
Je vais creuser; je présume que c'est pour la révision D0 du i7-920. Le mien est un C0.
 
Dans tous les cas de figure, j'espère rester à l'abri d'une mise à jour hâtive du fabricant.

n°10316412
Nono0000
Posté le 23-01-2018 à 21:28:57  profilanswer
0Votes positifs
 

Oui tu as raison, je me suis trompé de révision ;)


---------------
CPU: 6950X 4.3Ghz (Uncore: 3.7Ghz) WC HM -- Mem: 4x8Go 3200Mhz 14-16-17-32-1T -- Mobo: Asus X99 Deluxe -- GPU: 4080 (GPU: 3015Mhz, VRAM: 12200Mhz) -- Carte Son: X-Fi Titanium Fatal1ty Professional -- SSD: M.2 PCIE XP941 -- Ecran: DELL AW3423DW QD-OLED
n°10316504
scorpio810
Posté le 23-01-2018 à 23:47:35  profilanswer
0Votes positifs
 

http://kroah.com/log/blog/2018/01/ [...] -status-2/
 
Edit :
gcc-7 (7.2.0-20) unstable; urgency=medium
 
  * GCC 7.3 release candidate 2.
  * Update to SVN 20180122 (r256970) from the gcc-7-branch
  *....
 
Plus qu'a recompiler le 4.14.15..


Message édité par scorpio810 le 24-01-2018 à 00:36:12
n°10316533
EDIMKA
Posté le 24-01-2018 à 02:40:31  profilanswer
0Votes positifs
 

Bon sinon moi j'ai un problème de son qui grésille quand je bouge le curseur du volume, j'ai tout essayé, changement de CM, d'alim, nouvelle caisse, nouveaux casques (jack et USB), nouvelle prise électrique, réinstallation de Windows 10, réinstallation du driver générique, installation du pilote audio realtek, j'ai également acheté un filtre anti-parasite enfin bref j'ai TOUT essayé selon moi et je ne trouve pas le soucis, je deviens dingue... La seule parade que j'ai trouvé et qui atténue les grésillement c'est relier mon casque en jack à mon écran et là j'ai vraiment l'impression que les grésillements sont réduits de 50%. AIDEZ MOI :(

n°10316577
Nicodonald
Posté le 24-01-2018 à 09:33:36  profilanswer
0Votes positifs
 

C_Wiz a écrit :


Au delà de son langage coloré et du fait qu'il a mélangé un peu des trucs, le fond du débat c'est que Intel pousse à ce que le patch Spectre soit Opt-in sous Linux, parce que l'impact sur les perfs est important.  
 
Il n'a pas tort ;) Les patchs ne sont pas acceptés pour l'instant de toute façon. Pour l'instant seul retpoline est mis en place au niveau du kernel, ce message parle des mitigations IBRS (celles qui reposent sur la maj microcode) qui sont en court de développement.  
 
Le consensus est que retpoline n'est pas suffisant dans pas mal de cas, et particulièrement sur Skylake+ chez Intel ou IBRS sera probablement obligatoire.


A la fois, il a pas tord, laisser la faille par défaut et corriger, si l'OS le demande ça ressemble fortement à du damage control pour ne pas que les futurs processeurs soient plus lents que les actuels.
Il se plaint également que le correctif est loin de ne faire que ça, sans explications il me semble

n°10316599
cpagrave
Posté le 24-01-2018 à 10:00:44  profilanswer
0Votes positifs
 

Il y a un site web qui a l'historique des microcodes?

n°10316608
guigotech
Posté le 24-01-2018 à 10:12:33  profilanswer
0Votes positifs
 

EDIMKA a écrit :

Bon sinon moi j'ai un problème de son qui grésille quand je bouge le curseur du volume, j'ai tout essayé, changement de CM, d'alim, nouvelle caisse, nouveaux casques (jack et USB), nouvelle prise électrique, réinstallation de Windows 10, réinstallation du driver générique, installation du pilote audio realtek, j'ai également acheté un filtre anti-parasite enfin bref j'ai TOUT essayé selon moi et je ne trouve pas le soucis, je deviens dingue... La seule parade que j'ai trouvé et qui atténue les grésillement c'est relier mon casque en jack à mon écran et là j'ai vraiment l'impression que les grésillements sont réduits de 50%. AIDEZ MOI :(


 
Euh, mauvais catégorie non ? Sinon ce genre de truc c'est pas a cause de courants de fuite ? genre une mauvaise prise de terre ?

n°10316656
obyoneone
Posté le 24-01-2018 à 11:31:36  profilanswer
0Votes positifs
 

EDIMKA a écrit :

Bon sinon moi j'ai un problème de son qui grésille quand je bouge le curseur du volume, j'ai tout essayé, changement de CM, d'alim, nouvelle caisse, nouveaux casques (jack et USB), nouvelle prise électrique, réinstallation de Windows 10, réinstallation du driver générique, installation du pilote audio realtek, j'ai également acheté un filtre anti-parasite enfin bref j'ai TOUT essayé selon moi et je ne trouve pas le soucis, je deviens dingue... La seule parade que j'ai trouvé et qui atténue les grésillement c'est relier mon casque en jack à mon écran et là j'ai vraiment l'impression que les grésillements sont réduits de 50%. AIDEZ MOI :(


mauvaise terre ou blindage... mais ici on parle de microcode µp


Message édité par obyoneone le 24-01-2018 à 11:32:43
n°10316667
scorpio810
Posté le 24-01-2018 à 11:56:28  profilanswer
0Votes positifs
 

cpagrave a écrit :

Il y a un site web qui a l'historique des microcodes?


 
Sur Debian par exemple, on peut retracer l'historique des microcode intel, etc  
 
http://metadata.ftp-master.debian. [...] _changelog
http://metadata.ftp-master.debian. [...] _changelog

n°10316669
scorpio810
Posté le 24-01-2018 à 11:59:02  profilanswer
1Votes positifs
 

C_Wiz a écrit :


Au delà de son langage coloré et du fait qu'il a mélangé un peu des trucs, le fond du débat c'est que Intel pousse à ce que le patch Spectre soit Opt-in sous Linux, parce que l'impact sur les perfs est important.  
 
Il n'a pas tort ;) Les patchs ne sont pas acceptés pour l'instant de toute façon. Pour l'instant seul retpoline est mis en place au niveau du kernel, ce message parle des mitigations IBRS (celles qui reposent sur la maj microcode) qui sont en court de développement.  
 
Le consensus est que retpoline n'est pas suffisant dans pas mal de cas, et particulièrement sur Skylake+ chez Intel ou IBRS sera probablement obligatoire.


 
 
https://cdn.kernel.org/pub/linux/ke [...] og-4.14.15
 
x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros
   

    commit 28d437d550e1e39f805d99f9f8ac399c778827b7 upstream.
     
    The PAUSE instruction is currently used in the retpoline and RSB filling
    macros as a speculation trap.  The use of PAUSE was originally suggested
    because it showed a very, very small difference in the amount of
    cycles/time used to execute the retpoline as compared to LFENCE.  On AMD,
    the PAUSE instruction is not a serializing instruction, so the pause/jmp
    loop will use excess power as it is speculated over waiting for return
    to mispredict to the correct target.
     
    The RSB filling macro is applicable to AMD, and, if software is unable to
    verify that LFENCE is serializing on AMD (possible when running under a
    hypervisor), the generic retpoline support will be used and, so, is also
    applicable to AMD.  Keep the current usage of PAUSE for Intel, but add an
    LFENCE instruction to the speculation trap for AMD.
     
    The same sequence has been adopted by GCC for the GCC generated retpolines.
 
x86/retpoline: Fill RSB on context switch for affected CPUs
     
    commit c995efd5a740d9cbafbf58bde4973e8b50b4d761 upstream.
     
    On context switch from a shallow call stack to a deeper one, as the CPU
    does 'ret' up the deeper side it may encounter RSB entries (predictions for
    where the 'ret' goes to) which were populated in userspace.
     
    This is problematic if neither SMEP nor KPTI (the latter of which marks
    userspace pages as NX for the kernel) are active, as malicious code in
    userspace may then be executed speculatively.
     
    Overwrite the CPU's return prediction stack with calls which are predicted
    to return to an infinite loop, to "capture" speculation if this
    happens. This is required both for retpoline, and also in conjunction with
    IBRS for !SMEP && !KPTI.
     
    On Skylake+ the problem is slightly different, and an *underflow* of the
    RSB may cause errant branch predictions to occur. So there it's not so much
    overwrite, as *filling* the RSB to attempt to prevent it getting
    empty. This is only a partial solution for Skylake+ since there are many
    other conditions which may result in the RSB becoming empty. The full
    solution on Skylake+ is to use IBRS, which will prevent the problem even
    when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
    required on context switch.


Message édité par scorpio810 le 24-01-2018 à 12:28:58
n°10316697
C_Wiz
Profil : Equipe HardWare.fr
Posté le 24-01-2018 à 12:48:33  profilanswer
1Votes positifs
 

Un plan B est envisagé en ce moment : https://lkml.org/lkml/2018/1/23/25
 
Laissons les bosser ;)

n°10316724
xphanoo
Posté le 24-01-2018 à 13:26:47  profilanswer
0Votes positifs
 

Voilà ce que ça donne de faire des patch en urgence, on crée encore plus de problèmes qu'il y en avait.... on dirait que même les plus gros constructeurs ont oublié les process et nous sortent des trucs en mode agile à l'arrache. Bientôt les CPUs seront mis à jour automatiquement à distance comme le browser  :o


Message édité par xphanoo le 24-01-2018 à 13:29:33
n°10316839
SirGallaha​d
What's your favorite color ?
Posté le 24-01-2018 à 15:30:41  profilanswer
0Votes positifs
 

Ce qui est étrange en survolant leurs conversations, c'est qu'ils semblent pointer du doigt un problème de perf/sécurité plus grave sur les gen Skylake+ alors que j'avais compris que les pertes de perfs étaient plus importantes sur le vieux matos. C'est parce qu'ils parlent de 2 variantes différentes ou je n'ai pas compris ?

n°10316852
Profil sup​primé
Posté le 24-01-2018 à 15:47:54  answer
0Votes positifs
 

C_Wiz a écrit :

Un plan B est envisagé en ce moment : https://lkml.org/lkml/2018/1/23/25
 
Laissons les bosser ;)


 
Et pour Windows ?

n°10316900
B0lTiliZeR
Posté le 24-01-2018 à 16:41:42  profilanswer
0Votes positifs
 

VAG Powaaaaaaaaaaaaa!!!!
Mais la du coups on peut dire que c'est de l'obsolescence programmée ?

n°10316923
C_Wiz
Profil : Equipe HardWare.fr
Posté le 24-01-2018 à 17:38:48  profilanswer
2Votes positifs
 

SirGallahad a écrit :

Ce qui est étrange en survolant leurs conversations, c'est qu'ils semblent pointer du doigt un problème de perf/sécurité plus grave sur les gen Skylake+ alors que j'avais compris que les pertes de perfs étaient plus importantes sur le vieux matos. C'est parce qu'ils parlent de 2 variantes différentes ou je n'ai pas compris ?


Non tu as bien compris.

 

Retpoline (le patch au niveau du compilateur par Google pour limiter la spéculation) n'est pas effectif a 100% sur Skylake, parce que Skylake spécule "plus" que les générations précédentes et qu'il y a beaucoup de moyens d'attaquer retpoline sur Skylake. Retpoline semble une solution limitée aux gens qui contrôlent a 100% leur environnement (genre Google :p) et qui veulent limiter les pertes de perfs à tout prix (genre Google :p). Pour "corriger" la vulnérabilité plus globalement pour des usages plus larges (grand public) retpoline semble au minimum insuffisant (si on l'applique au kernel, ce que fait 4.14, ca ne protège que le kernel, les apps userland sont vulnérables entre elles, genre un navigateur web peut accéder au client mail et inversement) ou peu pratique (il faut recompiler toutes les applications pour protéger l'userland, ca se discute sur Linux, moins sous Windows :D).

 

C'est a la base pour ca qu'ils discutent du fait d'où activer IBRS et comment. Skylake devrait avoir au moins par défaut IBRS, les autres c'est plus discutable et y'a tout un débat.

 

Le débat c'est est ce que retpoline était une diversion/perte de temps ou pas, aussi.

 


Ce qu'a fait Microsoft, a notre connaissance, c'est appliquer les patchs les plus restrictifs mais aussi les plus surs (donc pas retpoline). Sous Windows, le KB mentionné plus haut applique KPTI (le patch meltdown) à tous les CPU (même les non Intel), et applique IBRS si il y a le support dans le microcode (le débat des BIOS de début janvier d'Intel).  

 

Ce que va faire Microsoft à l'avenir, on n'en sait rien. Retpoline ne semble pas une piste qu'ils envisagent (a raison), il n'y aura pas de support retpoline dans VCC par exemple (alors qu'il y a un support pour les autres techniques LFENCE & co). On aimerait bien savoir et comme tout le monde on attends le prochain patch pour voir ce qui se passe ;)

Message cité 1 fois
Message édité par C_Wiz le 24-01-2018 à 17:40:11
n°10316925
WizardPC
Posté le 24-01-2018 à 17:48:47  profilanswer
0Votes positifs
 

Pour mon problème de boot en boucle, réinstallation de windows obligatoire et blocage de Windows Update le temps que ça se tasse.. :o


---------------
Modding/Watercooling : PiBoy! ~ WaterBox // Achat / Vente !!
n°10316933
djayse
Posté le 24-01-2018 à 18:21:35  profilanswer
1Votes positifs
 

Autrement dit la vieille règle qui consiste à dire "quand ton PC fonctionne sans problème il ne faut jamais faire de mise à jour du bios" se vérifie également pour cette mise à jour du microcode.
 
Finalement à part faire les mises à jours windows il faut toucher à rien et attendre.

n°10317023
obyoneone
Posté le 24-01-2018 à 20:48:13  profilanswer
0Votes positifs
 

B0lTiliZeR a écrit :

VAG Powaaaaaaaaaaaaa!!!!
Mais la du coups on peut dire que c'est de l'obsolescence programmée ?


non puisque personne ne t'oblige à faire les maj....
perso j'ai tout bloqué avec oo shutup et autre script et basta, je reste à la 1703 brute pour un moment !(4790k)

Message cité 1 fois
Message édité par obyoneone le 24-01-2018 à 20:48:41
n°10317064
Profil sup​primé
Posté le 24-01-2018 à 22:17:15  answer
0Votes positifs
 

C_Wiz a écrit :


Ce qu'a fait Microsoft, a notre connaissance, c'est appliquer les patchs les plus restrictifs mais aussi les plus surs (donc pas retpoline). Sous Windows, le KB mentionné plus haut applique KPTI (le patch meltdown) à tous les CPU (même les non Intel), et applique IBRS si il y a le support dans le microcode (le débat des BIOS de début janvier d'Intel).  
 
Ce que va faire Microsoft à l'avenir, on n'en sait rien. Retpoline ne semble pas une piste qu'ils envisagent (a raison), il n'y aura pas de support retpoline dans VCC par exemple (alors qu'il y a un support pour les autres techniques LFENCE & co). On aimerait bien savoir et comme tout le monde on attends le prochain patch pour voir ce qui se passe ;)


 
Merci pour ces éclaircissements  :jap:  
 

obyoneone a écrit :


non puisque personne ne t'oblige à faire les maj....
perso j'ai tout bloqué avec oo shutup et autre script et basta, je reste à la 1703 brute pour un moment !(4790k)


 
C'est idiot, les màj sont cumulatives et corrige(ro)nt d'autres problèmes, et comme déjà dit on peut désactiver le(s) fix Meltdown et/ou Spectre via des clés de registre. Inspectre le fait en un clic.

n°10317107
scorpio810
Posté le 25-01-2018 à 00:34:32  profilanswer
0Votes positifs
 

Recompilé le kernel 4.14.15 avec GCC 7.3
 
Spectre and Meltdown mitigation detection tool v0.32
 
Checking for vulnerabilities on current system
Kernel is Linux 4.14.15-vanilla #1 SMP Wed Jan 24 22:00:42 CET 2018 x86_64
CPU is AMD Ryzen 7 1700X Eight-Core Processor
 
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO  
    * CPU indicates IBRS capability:  NO  
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO  
    * CPU indicates IBPB capability:  NO  
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO  
    * CPU indicates STIBP capability:  NO  
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO  
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO  
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO  
* CPU vulnerability to the three speculative execution attacks variants
  * Vulnerable to Variant 1:  YES  
  * Vulnerable to Variant 2:  YES  
  * Vulnerable to Variant 3:  NO  
 
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)
 
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Mitigation 1
  * Kernel is compiled with IBRS/IBPB support:  NO  
  * Currently enabled features
    * IBRS enabled for Kernel space:  NO  
    * IBRS enabled for User space:  NO  
    * IBPB enabled:  NO  
* Mitigation 2
  * Kernel compiled with retpoline option:  YES  
  * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
  * Retpoline enabled:  YES  
> STATUS:  NOT VULNERABLE  (Mitigation: Full AMD retpoline)
 
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI):  YES  
* PTI enabled and active:  NO  
* Running under Xen PV (64 bits):  NO  
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)
 
A false sense of security is worse than no security at all, see --disclaimer
 
 
 grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline
 
cat /boot/config-`uname -r` | egrep "CONFIG_PAGE_TABLE_ISOLATION|CONFIG_RETPOLINE"
CONFIG_RETPOLINE=y
CONFIG_PAGE_TABLE_ISOLATION=y


Message édité par scorpio810 le 25-01-2018 à 09:52:47
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4

Aller à :
Ajouter une réponse
 

Sujets relatifs
[HFR] Actu : NZXT lance une… carte mère ![HFR] Actu : Samsung atteint 2.4 Gbps en HBM2
[HFR] Actu : CES: Un écran OLED 4K 21.6 pouces chez Asus ![HFR] Actu : CES: L'Exynos 9810 de Samsung en image
[HFR] Actu : CES: Thermaltake annonce son Level 20 
Plus de sujets relatifs à : [HFR] Actu : Microcode Intel beta la semaine prochaine


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR