COMPTOIR
  
register

Et une faille de plus chez Intel : LazyFP

Après Meltdown & Spectre, leurs variantes et les autres spécifications brumeuses du jeu d'instruction x86, le hardware a la vie dure au niveau sécurité ces temps-ci. Malheureusement, le phénomène ne va pas en s'améliorant : une nouvelle vulnérabilité vient juste d'être rendue publique, qui concerne une fuite au niveau de l'unité s'occupant des calculs sur nombre à virgule flottante.

 

La faille a été découverte par une collaboration d'Amazon et de Cyberus Technology ; et le coupable est, une fois encore, l'exécution spéculative. En effet, lors des changements de processus exécutés sur un cœur physique, sous certaines conditions (liées à une évaluation dite paresseuse de registres, un mécanisme permettant normalement d'éviter certaines écritures et ainsi gagner en performances), le contenu des registres associés aux extensions MMX, SSE et AVX peut être accédé par un processus autre que celui l'ayant écrit. On notera que tout comme Spectre, un canal auxiliaire et nécessaire à l'attaque, c'est-à-dire que la valeur n'est pas directement lisible par le processus attaquant. Et tout comme les failles précédentes, cette dernière est particulièrement embarrassante dans le cas d'un serveur mutualisé faisant tourner différentes machines virtuelles, car les registres touchés peuvent contenir des informations sensibles telles des clefs SSH sécurisant l'accès à ladite machine virtuelle voisine.

 

Fort heureusement, un fix serait déjà disponible sous Linux (une option passé au démarrage du noyau permet de désactiver la fonctionnalité incriminée), et - fait amusant - elle pourrait même améliorer les performances sous certaines charges de travail. Seuls les processeurs d'architecture Core à partir de Nehalem sont a priori touchés, AMD tout comme ARM se retrouvant épargnés par cette histoire ; mais c'est à se demander tout de même si le x86 ne se serait pas développé un peu trop vite, au détriment de la sécurité de ses utilisateurs...

 

intel

 

Un poil avant ?

Steam offre encore quelques mois de survie à XP et Vista

Un peu plus tard ...

De la DRAM cristalline et glamour ? Oui, G.Skill a osé !

Les 15 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un champion du monde embusqué, le Lundi 18 Juin 2018 à 21h45  
la fiabilité chez intel est vraiment en chute libre ces derniers mois .... mais pas leur prix
par Nicolas D., le Samedi 16 Juin 2018 à 07h51  
par Un champion du monde embusqué, le Vendredi 15 Juin 2018 à 13h18
Autant en général j'ai tendance à crier alerte lors d'une telle faille mais celle-ci je pense que sa gravité peut être relativiser par le fait que les registres MMX, SSE et AVX sont des registres utilisés pour de la performance (ces extensions comportent des registres de 128 à 512 bits et il est par exemple possible d'effectuer 4 à 16 additions 32 bits en un cycle sur ces registres).
Le MMX est si vieux que le compilateur va l'utiliser des que possible (pas de soucis de rétrocompatibilité, tous les CPU 64-bits en sont équipés), et c'est quand même très simple de trouver deux additions indépendantes à paralléliser (cf cas d'OpenSSH dans un commentaire précédent ).
par Zoroastre, le Vendredi 15 Juin 2018 à 23h17
l'exécution spéculative on peut s'en passer apparemment si on code proprement
Les xbox 360 et ps3 en était dépourvut pour économiser du transistor et les devs ont du se sortir les doigts du fion pour sortir quelques perles sur ces machines
Hum c'est a demi-vrai, à l'époque les consoles étaient sous une architecture complètement différente du x86, et il n'est pas dit que l'exécution spéculative puisse être totalement comblée par des optimisations software. Surtout que à ce niveau de granularité, la balle est plus dans le camp des compilo que des devs en général
par Zoroastre, le Vendredi 15 Juin 2018 à 23h17  
l'exécution spéculative on peut s'en passer apparemment si on code proprement
Les xbox 360 et ps3 en était dépourvut pour économiser du transistor et les devs ont du se sortir les doigts du fion pour sortir quelques perles sur ces machines
par jkonéri1, le Vendredi 15 Juin 2018 à 21h17  
Quand tu achètes une poubelle neuve logiquement elle est vide, c'est par la suite quand tu l'utilises qu'elle est pleine d'ordures, l'X86 c'est pareil
par Loustic embusqué, le Vendredi 15 Juin 2018 à 18h23  
Le X86 n'a jamais été pensé pour la sécurité en réseau donc forcément... Ainsi les découvertes de failles ne font que commencer et la réalité c'est que si on veut vraiment de la sécurité c'est bien l'architecture qu'il faut revoir. C'est pas la rustine Hardware des prochains CPU qui sort l'année prochaine chez Intel/AMD qui changera la donne...
par Xorg, le Vendredi 15 Juin 2018 à 16h21  
Nouvelle mode : la recherche des failles de sécurité matérielles.
Comme quoi, la spéculation, c'est jamais bon. Intel aurait dû le savoir avec le Krach de 1929.
Au rythme auquel on découvre de nouvelles failles chez Intel, ça donne un nouvel argument pour acheter du AMD. Au lieu de sortir un refresh (Whiskey Lake) du refresh (Coffee Lake) du refresh (Kaby Lake), Intel aurait plus à y gagner en sortant une nouvelle architecture sans ces failles...
par UpsiloNIX, le Vendredi 15 Juin 2018 à 16h14  
par Un champion du monde embusqué, le Vendredi 15 Juin 2018 à 13h18
Autant en général j'ai tendance à crier alerte lors d'une telle faille mais celle-ci je pense que sa gravité peut être relativiser par le fait que les registres MMX, SSE et AVX sont des registres utilisés pour de la performance (ces extensions comportent des registres de 128 à 512 bits et il est par exemple possible d'effectuer 4 à 16 additions 32 bits en un cycle sur ces registres).

Donc ils ne devraient normalement pas contenir des informations sensibles. Après je peux me tromper, peut-être qu'ils ont utilisés pour manipuler plus rapidement une clef SSH ?
Quelqu'un a-t-il un avis sur la question ?
C'est juste utilisé par OpenSSL (entre autre), pas grand chose

Source : https://software.intel.com/en-us/articles/improving-openssl-performance
par Un rat goth à l'heure embusqué, le Vendredi 15 Juin 2018 à 15h53  
"...c'est à se demander tout de même si le x86 ne se serait pas développé un peu trop vite, au détriment de la sécurité de ses utilisateurs..."

Le problème est (encore) l'exécution spéculative; pour des gains de vitesse, ils ont pris des raccourcis et on voit où cela mène !
Ce qui est triste, c'est de voir le nombre de générations de CPU touchés; forcément, à chaque fois ils font du neuf avec du vieux...
Est-ce la fin de la génération Core ? (surtout avec le retour d'AMD)
Quand on pense que ces processeurs (x86) ne font qu'émuler du x86 sans en être vraiment depuis belle lurette.
par Kam7r, le Vendredi 15 Juin 2018 à 14h56  
par Un ragoteur de transit embusqué, le Vendredi 15 Juin 2018 à 13h16
Avec autant de failles connues chez les bleus je sens que mon prochain CPU viendras de chez Lisa même si ils sont un peu en retard en jeu (mon utilisation principale, mais ils sont dans la limite acceptable) ils sont costauds en applicatif (je fait pas mal d'archivage LZMA2/.7z).
moi j'ai sauté le pas, je passe d'un i5-4570 a un ryzen 2600... c'est ptet pas 100% safe, mais c'est moins pire qu'intel
par Un ragoteur tout mignon embusqué, le Vendredi 15 Juin 2018 à 13h46  
Pif Intel .. on es les mellieur certe mais en enculade seulement
par LiquidNitrogen, le Vendredi 15 Juin 2018 à 13h26  
par pouet26 embusqué, le Vendredi 15 Juin 2018 à 13h00
Juste comme ça... Il y a un paquet de fautes
Juste comme ça... T'as pas mis de point à la fin de ta phrase.
par Un champion du monde embusqué, le Vendredi 15 Juin 2018 à 13h18  
Autant en général j'ai tendance à crier alerte lors d'une telle faille mais celle-ci je pense que sa gravité peut être relativiser par le fait que les registres MMX, SSE et AVX sont des registres utilisés pour de la performance (ces extensions comportent des registres de 128 à 512 bits et il est par exemple possible d'effectuer 4 à 16 additions 32 bits en un cycle sur ces registres).

Donc ils ne devraient normalement pas contenir des informations sensibles. Après je peux me tromper, peut-être qu'ils ont utilisés pour manipuler plus rapidement une clef SSH ?
Quelqu'un a-t-il un avis sur la question ?