Après de nombreux OEM, Microsoft s'est également décidé a désactiver son patch pour la faille Spectre (Variante 2) suite aux problèmes de plantages notés avec ...
Lire la suite ...

on a pas fini d'entendre parle de ces failles qui touchent à la conception même des processeurs x86.

Et après on me jette des pierres quand je dis qu'Intel ne dispose plus des "sachants" ....  

quel bazar ! dans le genre super mauvaise gestion de crise j'ai demandé Intel !..... je trouve ca ahurissant de nullité leur facon de gérer toute cette affaire.... franchement, ils sont vraiment en dessous de ce que l'on peut attendre d'eux.

Pour ma part pas de soucis avec un i7-6700K avec Bios à jour (Asus Z170 Deluxe - 3703) et Win 10 à jour.
 
Quelqu'un a eu des soucis de stabilité parmi les lecteurs de Hardware.fr ?

Quelqu'un pourrait nous éclairer sur cette partie ?
Et par dérivés, ils parlent de tous les processeurs sorties depuis Skylake ? Coffee Lake est donc aussi touché ?

 
On en a parlé sur d'autres threads il me semble, pour faire simple, Spectre V2 repose sur la manière dont les processeurs spéculent dans leur exécution d'instruction. Plus précisément, Spectre V2 joue sur la manière dont les processeurs spéculent sur le retour des fonctions.
 
retpoline (voir là https://support.google.com/faqs/answer/7625886 ) est un mécanisme (return trampoline) qui tente d'isoler les endroits exploitables au niveau du compilateur pour faire court.
 
Le problème de Skylake est qu'ils spéculent différemment sur les retours de fonction avec des mécanismes plus "évolués", qui font que retpoline semble exploitable sur Skylake. C'est le consensus dans le monde Linux (qui est le seul ou cela parle vraiment parler ouvertement, c'est les employés d'Intel qui ont indiqué dès le début que retpoline ne suffirait pas pour Skylake+) : https://lkml.org/lkml/2018/1/4/708  
 
Il y a des messages plus récents ou ils expliquent plus en détail pourquoi retpoline est insuffisant sur Skylake mais je ne les ai pas sous le coude.  
 
Et oui tous les dérivés de Skylake sont concernés, c'est la même architecture (donc Kaby Lake et Coffee Lake, et probablement les -X aussi même si pas vu de confirmation).

Pas que, des CPUs avec d'autres archis que x86 (arm par exemple) sont également touchés.

Je suis pas prêt d'avoir un BIOS pour mon vieux i7-3770K "Ivy Bridge"... et pourtant j'utilise une carte mère Intel, modèle DZ77GA-70K. C'est la poisse...
Intel pouvait exceptionnellement, et malgré la période de support technique dépassée, pousser un BIOS corrigé. Même avec les fameuses failles du Management Engine dévoilées les années précédentes ils n'avaient pas bougé. Première et dernière fois en carte mère Intel.

Ce n'est pas limité aux cartes intel. Hélas...

Qu'en est-il des microcodes AMD? Ils parlaient de mi-janvier mais je n'ai pas vu de nouvelles depuis. Ils ont été mis en place chez des partenaires ?

La mise à jour se contente de créer deux clés de registre qui remettent Spectre à "no" pour les tests Steve Gibson et AShampoo. Discipliné, bien que n'ayant aucun problème de stabilité avec mon i7-6700K/Asus Z170 deluxe j'ai effectué cette MAJ Microsoft. Je me contenterai de dire "quel bordel !"

On peut apprécier le professionnalisme de Intel et Microsoft qui ont pour le premier fourni un Microcode totalement buggé et qui finalement ne sert à rien et pour le second fourni une mise à jour qu'il doit désactiver en catastrophe via une énième mise à jour ....
 
Une pensée pour ceux qui ont fait la mise à jour du bios de la carte mère et dont le PC plante sans arrêt après ça ...

S'il y avait que les PC perso ... en ce moment, c'est la panique dans les datacenters.

vu la merde que c'est j'ai juste fait le KB pour meltdown sur le fixe est le portable est c'est tout le reste wait and see, pas envie justement de me trouvé avec 2 PC plein de bug à devoir reinstall
le bios du fixe pas concerné y à plus de mise à jour dessus depuis fin 2015 du côté de gigabyte (à part des versions support pour broadwell mais je m'en cogne)    
 

 
donc en proc intel aussi alors?

Rien qu'un BSOD environ toutes les 48h, et ce depuis les dernières mises à jour...    
Alors que je n'en avais eu qu'un ou deux sur les 4 ans de mon laptop.

 
Je suis dans le même cas qu'Icetdrinker. En presque trois semaines d'utilisation pas un crash ou BSOD...
Cela dépend vraiment des systèmes visiblement...

Aucun soucis sur le fixe (haswell) mais problème d'exctinction et d'allumage de temps en temps (1 fois sur 2/3) depuis la maj sur le portable (broadwell) 'fin rien de dramatique par rapport a certains  
Les deux en w10 64 mais le fixe en version pro le portable famille (écran tactille pivotable et mode tablette)  

Rien à signaler sur un i7 8700K et une MSI Krait. Ca a l'air assez random comme truc, ce qui me semble complètement incompréhensible.

Mon avis est simple : côté intel, il n'y a pas de solution si ce n'est proposer du nouveau matériel.
En vérité, il y a tant de failles, hormis ces deux là, qui peuvent impacter les utilisateurs (dont de plus en plus d'arnaques aux boites courriels), que franchement c'est en effet surtout au utilisateurs et revendeurs de logiciels de faire attention. Est ce la faut à Intel si on exécute un virus sur son ordinateur capable de faire griller le processeur ?
Si c'était le cas, on aurait plus de processeurs overclockable à la vente et cela ferait des malheureux. (dont l'impression de "peut être" avoir un peu plus que ce pour quoi on a payé)
Le mieux reste, dans cette affaire, de faire comme microsoft le propose : de bloquer les possibilité de façon logicielle.
Certains se rappellent sans doute d'une époque où, avec microsoft office, on pouvait avoir des powerpoint ou fichier excel ayant du code VB malicieux s'exécutant automatiquement et pouvant endommager certaines choses ?
Résultat, microsoft propose depuis 2003 il me semble une version d'office qui bloque automatiquement les code automatique, sauf si l'utilisateur l'autorise spécifiquement.

Pareille pas de problème jusqu'ici avec la dernière MAJ Gygabite (alpha). j'ai vue qu'il avais sortie la MAJ en beta mais en attendant qu'ils soient un peu plus sur cher Intel je vais en rester à ces MAJ.

Heureusement qu'ils ont eu 6 mois pour bosser sur les patchs....

c'est random comme le mode de fonctionnement des procs, ont peut pensé que comme chaque procs fait ces propres spéculation forcement les résultats sont pas toujours strictement identiques car chaque machine n'a pas exactement les mêmes ressources à exloiotées ni les mêmes choses à exécutés à l'instant T, sans compter les divers modification du registre du moins je le conçoit comme ça, j'ai bon ou pas    
peut être aussi pour ça que c'est autant la merde à gérer ce genre de souci, pour un peu que ce soit lié au prefecht pour être encore plus précis ou une autre connerie du genre ça te fait autant de disparitées que de personnes qui utilise un ordi  

 
Pas de chance J'ai un OC léger qui tourne peut-être que des OCs plus violents jouent ? La RAM etc...
 
Vivement que l'industrie décide de mettre la sécurité au coeur de leur design plutôt que d'économiser en transistor pour avoir ce genre de merdes...
 
Peut-être une nouvelle archi ?

Non.

 
faire des sauvegardes de son système régulièrement
une image disque ou un clonage, et fini les problèmes!

Non, dont les processeurs spéculent sur les *appels* de fonction, et les retours en plus pour Skylake+.
 

Car avant Skylake, les retours n'étaient pas spéculés, empêchant la fuite d'information et donc la faille spectre. En gros, retpoline transforme les appels à des fonctions privilégiées en retour de fonction (en faisant un faux appel, en changeant l'adresse de retour, puis en faisant un retour), qui ne seront pas spéculés.
 
Pour faire simple, car en plus un trampoline c'est un appel dont la destination n'est pas connue au chargement du programme, mais seulement résolu lors du premier appel, qui patch le trampoline une fois exécuté la première fois pour le transformer en appel simple.
 

Oui, Skylake et suivants sont plus évolués et savent spéculer les retours, d'où le contournement par retpoline qui ne sert à rien car le CPU sait spéculer, et donc potentiellement révéler de l'information privilégiée.
 
Bref, Skylake étant encore plus « intelligent », il est encore plus sensible à la faille spectre. Seuls évitent la faille les CPU « bêtes », et donc moins rapides, et c'est assez emmerdant à résoudre du coup…

c'est un peu short je suis pas mieux avancé    

L'informatique c'est déterministe, si ça se comporte d'une façon dans une machine, ça fera pareil dans une autre. Un processeur a un microcode précis, il ne fait pas (encore ?) d'intelligence artificielle à sa sauce qui pourrait varier d'une machine à l'autre. (même si certains commencent à parler de "réseaux de neurone" dans le CPU)

et pourtant 2 ordis a priori identiques n'utiliserons pas les mêmes ressources au même moment suivant l'utilisateur ça ont le sait depuis le prefetch si c'est pas de l'apprentissage faut redéfinir le terme
donc les procs tournent tous pareil et sont "con" mais pas avec la mêmes choses à manger donc le soucis vient de l'OS pour les soucis random si je suis le raisonnement qui lui devient de plus en plus intrusif et intelligent à mesure des évolutions
 

Le random ça reste statistique, si ça arrive sur une conf, il est très probable que ça finisse par arriver sur une autre.  
 
Bref c'est une piste intéressante mais à mon avis les différences sont à chercher ailleurs (modèle de CPU, version de microcode, etc.)

 
C'est très intéressant, merci pour tous ces détails et explications  
 
Mais je n'arrive pas à comprendre la subtilité entre la spéculation sur les appels de fonctions et celle sur les retours de celles-ci.
 
Parce que l'objet d'une fonction sera (grossièrement) de faire un traitement, le résultat de celui-ci étant ce qui nous importe et sujet à stockage (criticité potentielle de l'information en résultant).
 
On pourrait ainsi très naïvement résumer un "appel" de fonction à son "retour" (même si les adresses ne sont pas les mêmes en mémoire) : quelle différence y-a-t'il entre ces deux types de spéculations, donc ?
 
BONUS : la seconde (spéculation sur les retours de fonctions) est-elle possible et / ou pertinente sans la première (spéculation sur l'appel de fonctions) ?
 
Si l'on pouvait m'éclairer, ça m'intrigue vraiment.
 
Merci  

Non, justement, dans le cas de Spectre la fonction n'est jamais exécutée du point de vue du processus appelant, puisqu'il n'a pas les privilèges nécessaires (dans le cas d'appels qui veulent exploiter la faille). Donc aucune influence du « retour » potentiel de cette fonction.
 

Spéculer sur les retours, c'est juste une optimisation pour aller plus vite. Avec ou sans optimisation de l'appel, on s'en fout un peu, à la base ces mécanismes sont simplement pour aller plus vite globalement.
 
C'est juste qu'un contournement « simple » de Spectre niveau soft pour mettre tout le monde au même niveau (= pas optimisé) était d'utiliser un retpoline, mais que sur Skylake bah ça ne permet pas d'éviter la faille.

C'est bien la prédiction des retours, précisément de l'instruction x86 RET, et la manière dont ça diffère qui joue, oui.  
 
L'explication de retpoline ( https://support.google.com/faqs/answer/7625886 ) donne pas mal de détails, si je découpe :
 
Dixit Google :

 
La doc d'Intel précise un peu la manière dont ils l'implémente (c'est différent chez AMD en passant) et la ou ça coince :  
 

 
Le RSB est un buffer (avec 16 entrées, high priority tout ça) rempli par le prédicteur.  
 
Google :

 
L'idée de retpoline c'est manipuler le RSB pour qu'il contienne toujours la bonne valeur et éviter toute spéculation :  
 

 
Pour le problème de Skylake+, y'en a plusieurs, le premier est expliqué par Google :
 

 
Il y a un problème potentiel de "vider" le cache, par exemple avec des tas de fonctions imbriquées. Si le cache est vide, on ne sait pas ce qui se passe (indice, il ne se passe pas la même chose sur Skylake+ que sur les archis précédentes). Des cas concrets ou on peut vider le cache :
 

 
Solution proposée par Google, s'assurer qu'il ne soit jamais vide (RSB stuffing) pour éviter le "comportement non défini".
 
lkml ( https://lkml.org/lkml/2018/1/26/606 ) pour faire le lien avec Skylake :

 
Le problème c'est qu'il y a un tas de cas ou le RSB peut être bypassé ( http://lkml.iu.edu/hypermail/linux [...] 07190.html ) et que l'on se retrouve dans le "cas non précisément défini" (et donc exploitable via Spectre V2) :  
 

 
(SMI, System Management Interrupt) https://en.wikipedia.org/wiki/Syste [...] tering_SMM
 
Bref, c'est compliqué sur Skylake !

Chez hp y a des nouveaux firmware depuis fin de semaine derniere
La secu nous a fait chier d appliqué de suite les nouveau bios et fameux patch
Et maintenant tu te retrouve avec plusieurs dizaine de becane super instable
Sauf qu appliquer des patch merdique et bios merdique sur une machine stable est une chose
Appliqué des pat h/bios stable sur des machine devenu instable à cause de leur gestion merdique dans la pricipitation de la chose c est une autre paire de manche
 
Comme d hab faut surtout pas ecouter les gars qui le vive sur le. Terrain, faut insister dans l ordre debile "rien a foutre applique quand meme alors que suite à ça les machine deconne"
 
Puré ce monde marche vraiment sur la tete

Et alors ? Tu décris l'exemple typique de décisionnaires qui n'ont aucune culture technique et encore moins de sensibilité sur le contexte. Ils le savent qu'il y a des risques d'instabilité, mais le fait de se rendre conforme est plus important que la stabilité des bécanes.
C'est après la bataille, au moment de compter les points Benco, qu'on mesurera les mauvaises décisions prises dans la précipitation. L'indisponibilité générée par ces incidents vont avoir des répercussions économiques sur la boîte. Il faudra trouver des responsables ... et il est fort à parier que ces fameux décisionnaires vont avoir chaud aux fesses.

Surment pas les décisionnaires comme tu dit j'ai les mêmes dans ma boite (pas du tout le même secteur) ce sont des gestionnaires purement financier il n'ont aucune connaissances du secteur, si ça merde, les répercussions redescendes gentillement les échelons jusqu'en bas et t'en prend plein la tête, quand bien meme t'a prévenus que tu fesait de la merde, car toi t'a forcément fait une erreur d'une façon ou d'une autre    

Des retours utilisés pour faire des jump/call de manière à tromper le prédicteur, pour être clair (j'espère). Mais oui, on doit être d'accord.
 

Pour qu'il contienne une valeur bidon qui va tromper le prédicteur. Par contre merci beaucoup des références détaillées, je n'avais lu qu'en diagonale le papier de Google, et donc je corrige ce que j'ai dit : les retours sont apparemment également prédits sur beaucoup de CPU, mais on peut manipuler le prédicteur de manière à ce qu'il n'exécute pas spéculativement d'instruction sensible, contrairement au jump/call indirects qu'on ne peut pas manipuler.
 

Effectivement, merci pour la réponse détaillée, c'est très instructif. Je vois pas trop comment Intel va se démerder avec Skylake+...

J'ai un i7 8700k, j'ai fait strictement zero mise a jour et je vois aucun probléme par rapport a avant...
 
je suis un gros gamer et si différence en jeu il y avait je l'aurai senti a moins que cela soit vraiment trop faible a constater
 
beaucoup de gens jouent le ton de la catastrophe ou je rêve ?