Reprise du message précédent :

Vu qu'on va ressortir les 486, autant se souvenir des films de l'époque

C'est étonnant de voir combien le colossal château de sable/silicium a des pieds d'argile

Et actuellement, les pieds, ils sont bien enfioncés dans la merde

Dernz

NOP

Pour info, un endroit où sont centralisés les patches/mises à jour/correctifs concernant Meltdown et Spectre
https://github.com/hannob/meltdownspectre-patches

bonjour,
 

bonsoir,
c'est trop calme par ici

Mettez ça à fond pour réveiller vos voisins.
https://www.youtube.com/watch?v=a6BbvCC0VI0

https://www.amd.com/en/corporate/speculative-execution
 
bonalorsquoi? Finalement coté AMD c'est pas si grave ?  
 
io  

Android
Super pour les équipements plus mis à jour (ou qui refusent de l'être)  

 
Problème de l'informatique moderne et des concepts "d'OEL" : dés qu'un CPU est OEL, alors qu'il contient du software (puisque c'est devenu des firmware comme tout le reste dans un PC) il ne sera pas patché. Et vu que firmware = blob binaire, souvent on va te dire "à mais mon bon monsieur/madame, on ne vous fournira pas les spec parce que c'est soumis a secret industriel".
Pour le coup, la "faille" pourrait avoir du bon puisque les blobs sont exposés au dasm et au dump par celle-ci. Faut juste que des personnes prennent le temps de se pencher sur la question. (c'est pas gagné)
 
Les "failles"; je le redis, elles n'en sont pas réellement, elles sont la résultante de l'exploitation de théorèmes et paradigmes/philosophies qui ne sont pas adaptées a leurs environnement.
Tomasulo ne devrait être utilisé qu'en monoseat 1 core = 1 streamline = 1 thread = 1 appli. L'avènement des caches communs, des ring bus dans les CPU, au nom du dieu virtualisation et optimisation hard parce que tu comprend, c'est trop chiant de faire des appels mémoire propres et de minimiser les changements de contexte en prog', c'est ça qui a provoqué le point où nous en sommes.
 
'fin, je suis contente, on va avoir un vrai retour du boulot d'archi sys

Bonjour,

ton post me fait penser à ça (que tu as du déjà lire) :
https://zaitcev.livejournal.com/241876.html

 
L'approche est simpliste mais oui. Le problème étant le workload, le coût de dev' d'une archi et le coût de dev' sur une archi. Le x86 est tellement encré dans les usages généralistes qu'on est pas prêt de le voir disparaître, les gens fondeurs et dev' vont tout faire pour sauver 40 ans d'informatique (depuis le l'ibm pc xt)
 
On risque très fortement (niveau des discussions chez les archi ça tourne sur ça) de voir apparaître des cpu guest et chipset host, parce que les utilisateurs veulent pas voir disparaître l'approche software actuelle. (hi, kékou l'archi power)

Nan, moi je penche pour un retour aux chèvres et aux pulls en laine équitable dans le Larzac ou tout autre coin paumé

Petite remarque comme ça en passant

Hier en jouant avec une des failles Spectre (celle qui joue sur la prédiction de branchement et les caches pour arriver à deviner la valeur d'un octet en mémoire), je me suis aperçu que quand ce genre d'exploit est utilisé, les "cache misses" pètent le plafond et sont très facilement repérables

D'autre part, vu la dépendance au cache de ce genre de truc, je me demande si y'a pas moyen de venir les perturber de ce côté là et venir foutre par terre leurs tentatives de devinette octet par octet de la mémoire

 
C'est la principale piste pour fixer le hard sans perte de perfs : faire tourner le CPU x86 en guest sur un système host non online et totalement isolé qui viendrait ne gérer qu'une seule chose : la cohérence des caches et leurs randomisation : le CPU s'en fout de l'ordonnancement du cache d'instructions, si il est randomisé en permanence et sans présence de registre, théoriquement tu ne peux plus timer les cache miss, reste les caches de données servant à la prédiction de branchement et là ben y'a pas de solution qui fasse pas perdre de perfs, hormis introduire une randomisation dans l'accès de 1 cycle (en gros tu allonge le temps d'un cycle d'accès au cache de manière aléatoire pour fausser le calcul de la time attack).
 
Sinon, faut changer de paradigme et ne pas faire du harvard amélioré ou pseudo von neumann.

Heu ... en fait c'est pas de 1 cycle qu'il faut fausser le temps d'accès au cache ...
Mais dans les 100/200, à vue de nez je dirais, vu que la plupart (toutes ?) des versions/PoC qui exploitent cette faille se sert de la différence de timing entre un accès à une donnée dans le cache vs une donnée qu'il faut rapatrier de la mémoire centrale pour deviner la valeur d'un octet en mémoire sans y avoir accès

En gros, faudrait soit rendre la DRAM aussi rapide que les caches, soit rendre les caches aussi lent que la DRAM  

On est pas encore près d'avoir le cul sorti des ronces avec cette histoire  

Sinon, apparemment, Intel aurait rajouté des bons gros LFENCE forcés dans la nouvelle version du micro code qu'ils distribuent suite à ce fiasco  

Et ça ferait des locks et autres bugs à ce qu'il parait…

Balancer des LFENCE comme ça à tout va, c'est du travail de goret fait à la truelle  
Il faudrait que ce soit les compilos qui les insèrent au bon endroit ( si c'est possible .... ) plutôt que de généraliser le truc ...

C'est soit ça, soit y'a vraiment du code de goret en exploitation un peu partout    
Et là, soit la faute en revient aux compilos, soit aux codeurs
 
 
Je sais pas lequel est le mieux, franchement ...

C'est pas étonnant ... Car si c'est que je pense, c'est pas du tout déterministe comme façon de procéder ...
Et dans certains cas, certaines exécution de branches spéculatives vont se terminer avant le LFENCE et pouvoir récupérer leurs données du cache,
alors que dans d'autres cas, la même exécution ne permettra pas de récupérer les résultats avant le LFENCE

J'ai l'impression que les mecs ont jeté de l'huile sur le feu, dans la précipitation, là  

Ou alors ils se disent qu'il vaut mieux avoir mal au fion qq temps, et que ça ira mieux une fois que la situation se sera décantée et que les softs auront été passés en revue/les compilateurs modifiés pour prendre en compte le problème
EDIT : En fait, c'est même pire que ça, suivant que tu lis  avant ou après un LFENCE, tu n'as aucune garantie que le résultat sera le même, tout ça pour la même instruction

Bon courage aux admins sys du topic pour les temps à venir  

En fait, même en rajoutant des LFENCE appropriés dans les softs recompilés, ça règle pas le problème des "rogue softs" qui eux, bien évidemment, n'inséreront pas les LFENCE nécessaires et pour cause ...

D'où le mouvement d'Intel ...

Il porte décidément bien son nom Spectre, en fait ...

En l'état actuel, cette histoire est insoluble ... On a aucun moyen, même au niveau du microcode de savoir quand c'est légitime d'imposer un LFENCE et quand ça ne l'est pas ...

J’ai rien compris.

J'ai l'impression que Intel a essayé d'imposer une "barrière mémoire" ( ?  en anglais c'est "memory fence/barrier" ), en modifiant son microcode, pour essayer de forcer l'ordre d'exécution des instructions de lecture/chargement de la mémoire et nettoyer le bordel du à l'exécution spéculative qui peut inverser l'ordre d'exécution de certaines instructions, et qui est utilisé/abusé dans la première variante de Spectre

Mais ils semblent avoir utilisé l'équivalent de l'instruction LFENCE qui entraîne des effets de bord à la con (en plus de couter des cycles machine pour s’exécuter complètement), notamment des effets non déterministes sur l'exécution d'un code (en gros, un coup ça marche/donne un résultat, la suivante, le même code ne marche pas/produit un résultat différent suivant la charge processeur, la sollicitation de la mémoire, des bus, l'âge du capitaine, les équinoxes, le coté de la tartine beurré)

LFENCE

J'espère que je me trompe dans mon interprétation et qu'ils n'ont pas fait ça

Memory fence
http://preshing.com/20120710/memor [...] perations/

Bon je pose ça ici, ça peut servir    
 
https://github.com/speed47/spectre-meltdown-checker

 
Y'a du code de goret, partout. Le premier code de goret qui déclenche des caches misses, c'est les firmware UEFI "designed for windows". Si t'as l'occasion essaye d'installer libreboot sur une machine, tu verra la différence.

Honnêtement, le temps passé à décortiquer le bouzin, ça a été une plongée au musée des horreurs ...
 
Ça donne pas franchement envie de revenir dans ce secteur d'activité ... y'a tellement de coups de pieds au cul/chevrotine qui se perdent
 
J'espère que les gens qui sont derrière les compilateurs y resteront longtemps/arriveront à transmettre leur savoir/expérience à des petits nouveaux motivés ...
 
Parce que sans ça, on va se prendre la baraque sur le coin de la gueule

Je crois que si je commence à parler de preuve/spec formelle, de Z, B et autres joyeusetés du même genre, soit on me regarde avec des yeux éberlués, soit on me jette des cailloux

Pour ma part, tout se qui est au dessus de l'OS, en principe je m'en occupe pas, mais quand je vois ce genre de trucs, j'ai aussi des envies de bataclouter.
 
Et y'a pas que les admin sys qui sont dans la merde, les archi aussi.

Putain, j'avais pas fait gaffe ... mais AMD, ils en tiennent une couche aussi ...
 
https://www.amd.com/en/corporate/speculative-execution

 
   
 
Ils espèrent quoi chez AMD de la part des éditeurs/développeurs d'OS ? Qu'ils vont être assez cons pour saboter leur OS pour leur faire plaisir ? Niquer tout ce qui permet d'obtenir un timing/mesure de temps un peu précise dans le système ou bourrer le fion aux caches en permanence, et charger les machines comme des mules, même en Idle ?
 
Ils pensent quoi ? Que le gentil pirate il va utiliser la dernière version de son compilateur qui aura pris soin de placer des LFENCE bien senti dans ses binaires pour bien niquer ses attaques futures ?
 
AMD  

Je suis dev, et j'aime pas quand un résultat n'est pas 100% le même pour la même question posée. Ca va être prise de tête....

 
Va pas voir ICC (intel C compiler) dans ce cas, parce que dans la catégorie explosion cosmique, lui, il en tiens une bonne en matière de sabotage de certaines arch (parce que justement son jeu est de bourrer le fion des caches et de jouer sur les timing notablement meilleurs sur intel que sur AMD). Rien de nouveau sous les tropiques. Et je parle même pas de clang/LLVM, d'ailleurs, tu devrais essayer clang/LLVM, tu va voir c'est funky les résultats (vue qu'il joue sur l'optimisation aarch)

En fait, la réponse d'AMD, ça se résume à dire "Allumez un cierge"    
 
 

Merci, je comprend un peu mieux.
Je sais que je rêve, mais on devrait pas virer les mecs qui ont codé ça et leurs supérieurs qui étaient au courant ?

 
Non, le dev' déterministe est une saloperie, quoi qu'en dise Zz.
 
C'est un peu comme minority report dans un CPU quoi, c'est beau sur le papier, mais vive les effets de bord.

bonjour,

du calme une lfence est une barrière sur le load (elle sérialise les load), donc c'est normal qu'elle n'ordonne pas les load vis-à vis des store, je ne vois pas o tu veux en venir  

"do a barrel roll"