Ces derniers jours, les rumeurs allaient bon train sur les réseaux sociaux suite à l’intégration en urgence d’un gros correctif dans la RC-6 du noyau Linux. Cela allait à l’encontre de toutes les habitudes de Linus Torvalds, ce qui laissait penser que les conditions étaient vraiment particulières. Et le moins que l’on puisse dire est que nous ne sommes pas déçus. Ce n’est pas une faille critique, mais deux, qui viennent d’être dévoilées : Meltdown et Spectre, de leur petit nom.
Nous vous invitons à lire le journal de Pinaraf< à ce sujet, bien qu’incomplet le jour où il l’a écrit. Depuis la date de sa publication, la faille Spectre a ensuite été révélée et, si cette dernière s’avère d’une ampleur moindre que Meltdown chez Intel, elle toucherait tous les fondeurs et la plupart de leurs produits).
Ces deux failles sont liées à l’architecture des processeurs modernes (Intel, AMD, ARM, etc.). Les processeurs sont capables d’aller très vite en utilisant un pipeline d’instructions : pendant qu’ils exécutent une instruction, ils sont déjà en train d’analyser les suivantes pour aller chercher à l’avance certains segments de mémoire. Les deux failles utilisent cela pour deviner ce que contient la mémoire dans des segments mémoire auxquels le processus courant ne devrait pas avoir accès. On parle de Side Channel Attack.
Ces deux failles sont critiques et des personnes bien informées considèrent que l’on ne pourra pas corriger totalement ces problèmes avant l’arrivée d’une nouvelle génération de processeurs, juste limiter les risques qu’elles soient exploitées.
Meltdown
Meltdown est une attaque qui vise le noyau et ne fonctionne qu’avec les processeurs Intel. Un processus peut tenter de deviner des segments mémoire du noyau. Les preuves de concept ont montré que c’est une technique efficace et non pas juste une faiblesse théorique. Bien qu’il ne soit pas possible de modifier la mémoire du noyau, il semblerait que ce soit suffisant pour sortir d’un conteneur Docker ou d’une machine virtuelle Xen.
Les principaux systèmes d’exploitation ont fourni ou vont fournir sous peu des mises à jour pour contrecarrer ces attaques. Ces mises à jour ont des impacts très notables en termes de performances, pouvant ralentir fortement certains traitements. Néanmoins, nous vous recommandons très fortement de faire ces mises à jour.
Spectre
Spectre est une attaque qui peut paraître moins violente à première vue ; elle ne permet à un processus que de deviner les segments mémoire d’autres processus sur le même ordinateur. Mais elle est beaucoup plus pernicieuse. D’abord, elle concerne tous les processeurs modernes et elle est vraiment liée à l’architecture des processeurs modernes. Il sera donc difficile de s’en débarrasser sans changer de processeur. D’autre part, les preuves de concept ont, là aussi, montré l’efficacité redoutable de cette attaque. Il est, par exemple, possible de pouvoir récupérer un mot de passe saisi dans un onglet d’un navigateur depuis le JavaScript d’un autre onglet.
Les principaux navigateurs travaillent à fournir des contre‐mesures (Mozilla et Chrome) par exemple. Mais ce sont loin d’être les seuls logiciels sur un ordinateur qui pourraient se livrer à de telles activités.
Que faire ?
Tout d’abord, rien ne sert de paniquer. À ma connaissance, personne n’a repéré d’attaques de ce type (ça pourrait passer inaperçu car ça ne laisse pas de traces sur le système, mais les personnes au courant ont fait de gros efforts pour voir si ces failles étaient déjà utilisées dans la nature, on peut donc leur accorder un certain crédit).
Ensuite, il est important de bien suivre les mises à jour, dans les jours qui viennent, mais c’est aussi une bonne habitude de manière générale. Et je ne parle pas que des mises à jour du système d’exploitation. Les navigateurs et globalement toutes les applications devront également être mis à jour régulièrement.
Les régies publicitaires sont connues pour être de mauvais élèves en termes de JavaScript. Je ne saurais que trop vous conseiller de vous tourner vers des extensions pour les navigateurs qui protègent votre vie privée comme uBlock Origin (Firefox et Chrome) ou NoScript.
Enfin, si vous avez un peu de temps, n’hésitez pas à vous renseigner sur d’autres sites et à recouper l’information. Cet article a été écrit en vitesse et est assez grossier. N’hésitez pas à ajouter des précisions dans les commentaires et à participer aux prochaines dépêches sur le site !
Aller plus loin
- Les papiers sur Meltdown et Spectre (530 clics)
- [Numerama] Meltdown et Spectre : 7 questions pour comprendre les failles critiques sur les processeu (1307 clics)
- A Simple Explanation of the Differences Between Meltdown and Spectre, by Daniel Miessler (337 clics)
- [Arstechnica] What’s behind the Intel design flaw forcing numerous patches? (172 clics)
- [The Register] Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign (188 clics)
- F**CKWIT, aka KAISER, aka KPTI – Intel CPU flaw needs low‐level OS patches (168 clics)
- Google Project Zero : Reading privileged memory with a side‐channel (166 clics)
- [LWN] Notes from the Intelpocalypse (236 clics)
- [CommitStrip] Les réactions aux failles Meltdown & Spectre (813 clics)
# La fin d’Intel
Posté par AncalagonTotof . Évalué à 5. Dernière modification le 04 janvier 2018 à 22:27.
N.B. : Je n’ai pas vérifié toutes mes infos, ni recherché de liens pour tout étayer.
Les signes ne sont pas brillants pour Intel :
Et la cerise sur le gâteau, un petit délit d’initié.
Good luck with that!
[^] # Re: La fin d’Intel
Posté par alpha_one_x86 (site web personnel) . Évalué à 4.
Intel as encore Intel Optane et les Xeon Phi
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: La fin d’Intel
Posté par Brice Goglin . Évalué à 6.
les Xeon Phi dont Intel a annoncé l'abandon du prochain en novembre ?
[^] # Re: La fin d’Intel
Posté par xcomcmdr . Évalué à 6. Dernière modification le 05 janvier 2018 à 09:23.
MS avait déjà essayé avec WinRT, qui fut un échec cuisant.
Cependant, que Windows 10 soit bientôt compatible ARM n'a rien de révolutionnaire.
La lignée Windows NT est déjà passé au cours de sa vie sur des plateformes différentes, telles que PouwerPC, et Itanium (IA-64/IA-32).
Quoi qu'il en soit, MS ne va pas lâcher x86/x86-64 avant que les poules aient des dents.
Bien que MS se soit diversifié, dominer le marché x86 reste une source de revenus importante, avec beaucoup de conséquences en termes de marché logiciel.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: La fin d’Intel
Posté par Christophe B. (site web personnel) . Évalué à 4.
C'est passé aussi vite qu'une étoile filante … en plein jour
[^] # Re: La fin d’Intel
Posté par xcomcmdr . Évalué à 4.
Comme l'Itanium. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: La fin d’Intel
Posté par Christophe B. (site web personnel) . Évalué à 8.
Sans rire … est ce que quelqu'un a vu en prod un NT sous Alpha ? ou autre chose que x86 ?
je n'ai rien vu d'autre que les CDROM d'installation (que j'aurais du garder … c'est collector maintenant)
[^] # Re: La fin d’Intel
Posté par totof2000 . Évalué à 5.
Oui, il y a longtemps. Je ne saurais plus dire par contre si c'était Alpha ou powerpc.
Sinon, j'ai bossé avec une appli qui ournait sur des machines équipées de processeurs Itanium, avec un windows dessus (me rappelle plus de la version par contre).
Ce sont les 2 seuls cas que je connaisse.
[^] # Re: La fin d’Intel
Posté par Anakon . Évalué à 5.
Lors d'une mission dans une caisse régionale d'une banque française, j'ai bossé sur un Alphaserver 1000A sous NT 4 qui hébergeait des bases SQL Server 7.0 pour leur GED. Les performances étaient plutôt bonnes.
Je suis parti de la mission avec la machine sous le bras (façon de parler hein ça pesait un âne mort), celle-ci ayant été remplacée par de l'Intel.
[^] # Re: La fin d’Intel
Posté par Foutaises . Évalué à 3.
Dans la première boîte pour laquelle j'ai bossé – partenaire Compaq —, notre serveur « technique » était un NT4 TSE qui tournait sur du DEC Alpha. Tout ce que je peux en dire, c'est que le truc faisait son travail sans se faire remarquer. :-)
[^] # Re: La fin d’Intel
Posté par Christophe B. (site web personnel) . Évalué à 8.
J'avais bossé sur un DEC Alpha mais sous ULTRIX
et c'était une bombe … pour l'époque
Et depuis j'ai jamais compris pourquoi Microsoft n'a pas poussé sur ce genre d'archi
car à l'époque les x86 ne tenait pas le choc surtout dans l'info de gestion
[^] # Re: La fin d’Intel
Posté par claudex . Évalué à 7.
Dont ils ont tirer les leçons. La nouvelles version sous ARM peut faire tourner les applications x86 via une émulation (assez performante semblerait-il).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La fin d’Intel
Posté par Prosper . Évalué à 10.
Ça fait déjà 5 ans qu'Apple a conçu son cpu https://fr.wikipedia.org/wiki/Apple_A7
[^] # Re: La fin d’Intel
Posté par bubar🦥 (site web personnel) . Évalué à 8.
Peut être pas la fin ?
Si ma ram ne déconne pas trop, la dernière grosse affaire qui s'approche de celle-ci, mais d'une ampleur bien moindre, c'est la faille dans Pacifica chez AMD, il y a une quinzaine d'années. Il s'agissait alors de proposer une isolation des flux pour les VM, qui chez AMD a mer** : tout se mélangeait, il était possible d'accéder à n'importe quoi, et il y avait en plus des bugs fonctionnels. C'était le temps de Vanderpool chez Intel et Pacifica chez AMD, des premières implémentations dans le matériel pour la virtualisation (il me semble).
L'affaire a fait moins de bruit, et était donc sur un périmètre incomparable avec l'ampleur de cette faille «meltdown» chez INTEL, mais elle a fait beaucoup de mal à AMD assez rapidement. Qui a mis 15 ans à se relever.
Alors peut être pas la fin de INTEL, mais en effet, dans le contexte que tu décris, la situation a bien tout les ingrédients pour faire très mal : un accident est toujours multi-factoriel parait il.
[^] # Re: La fin d’Intel
Posté par FantastIX . Évalué à 4.
Un échec ne justifie pas une fin.
Un échec est une invitation à faire mieux. Si un échec, quelle qu'en soit l'ampleur devait justifier la fin des activités en question, personne n'apprendrait… parce que c'est aussi (et surtout) en se trompant qu'on apprend!
À présent, oui, Intel sera sous la méfiance généralisée mais pas seulement: tous les fondeurs (AMD, Intel, les ARMistes …) ainsi que toutes les industries technologiques sont suffisamment pointées du doigt aujourd'hui pour ne plus pouvoir fermer les yeux sur toutes ces alertes à rectifier leurs conneries et à se remettre enfin en question.
Ce n'est que s'ils s'avèrent incapables ou rechignent à s'améliorer que ce sera fini pour eux. Et encore, j'ai un doute car c'est oublier de tenir compte de notre amnésie sur le long terme…
[^] # Re: La fin d’Intel
Posté par Thomas Douillard . Évalué à 7.
Oui et puis finalement, devenir fondeur de microprocesseur, c’est largement plus compliqué que de lancer une start-up logicielle. Ceux qui se sont lancé dans le hardware libre le savent bien.
Dans l’ensemble les coûts pour se lancer sur ce genre de marché sont tellement prohibitifs, à la mesure du coût des usines modernes, que seuls de très gros acteurs genre « la Chine » (quoi que ça veuille dire) peuvent le faire. Du coup on est en présence d’un oligopole ou les acteurs peuvent très bien s’entendre pour ne pas porter la compétition sur les questions comme la fiabilité des mesures de sécurité si ils ont envie, le consommateur aura peu de moyen de pression. Après il y a les gros clients et l’image de marque …
Mais tout ça c’est le marché du high tech. Ptete qu’il y a de la place pour une concurrence qui s’appuierait sur des technos plus éprouvées et moins coûteuse pour faire autre chose et se battre sur d’autres critère, comme minimiser le coût environnemental du cycle de vie et la sécurisation des puces, qui sait ? On a bien du matériel peu puissant mais à bas coût qui inonde le marché, de nos jours.
[^] # Re: La fin d’Intel
Posté par Alex G. . Évalué à 3.
Oui même si malgré tout les entreprises cotés en bourses sont très fragiles aux mauvaises nouvelles et surtout scandales (effet démultiplié et quasi instantané).
Après pour une boite comme Intel qui doit avoir un max de liquidité, je sais pas si ça permet de stabiliser la barque.
En tout cas il y aussi des nouvelles concurrence dans le monde des CPU, les ARM bien sur, mais aussi les GPU et les processeurs spécialisés AI (le TPU de google par exemple, ou graphcore qui a levé des millions de $).
Ça remplace pas le CPU classique mais ça répartit le marché (on met moins dans le CPU et plus sur le reste)
[^] # Re: La fin d’Intel
Posté par Thomas Douillard . Évalué à 9.
Bof, la baisse du cours n’a pas forcément tant d’impact que ça sur les bénéfices. Et elle n’est pas forcément durable.
Et pour la réputation, les entreprises font du « [whatever] washing» depuis bien longtemps et sont capables de bien des bassesses pour sauver la poule aux œufs d’or sans trop d’efforts.
[^] # Re: La fin d’Intel
Posté par nizan666 . Évalué à 10.
Des grandes entreprises capables de "bassesses" ?
Dis donc, je te trouve drôlement malpoli, limite impertinent vis à vis de ces champions de la croissance qui rendent, de plus, nos journées modernes grâce à leurs innovations merveilleuses.
Encore une remarque du genre et je serai contraint de te dénoncer à notre premier ministre, auteur il y a peu de ces mots sages (sur lesquels tu devrais méditer plutôt que sombrer comme tu viens de le faire dans ce genre de pensées négatives sur l'entreprise) : "Nous ne gagnerons rien du tout, ni vous ni nous, ni personne en France, à placer systématiquement le débat […] sur la production dans le thème du soupçon tel que vous venez de le faire".
# Debut pour OpenRISC?
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Debut pour OpenRISC? C'est ce que je me demande, vu que cela permettrai aux chercheurs en sécurité de regarder leur archi.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Linux, pas prêt ?
Posté par JN . Évalué à 3.
Un truc que je ne comprends pas : en regardant le fil sur LKLM, on voit ça,c'est-à-dire des patchs qui sont encore en cours de discussion sur une première proposition, alors qu'on est en fenêtre de stabilisation. Il y a eu un embargo de 6 mois, et on n'en est que là ?
À ce régime, comment peut-on annoncer que les kernels patchés seront dans nos distros sous peu ?
[^] # Linux prêt (pour Meltdown)
Posté par Arthur Accroc . Évalué à 8.
Parce que c’est déjà le cas pour Arch, CentOS 7, Debian…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Linux prêt (pour Meltdown)
Posté par JN . Évalué à 2.
Un petit bout, et encore, pas forcément stabilisé…
[^] # Re: Linux, pas prêt ?
Posté par amelliug . Évalué à 5.
Mise à jour également disponible dans fedora depuis hier
[^] # Re: Linux, pas prêt ?
Posté par zurvan . Évalué à 3.
est-ce que quelqu'un l'a installé et ça donne quoi au niveau du dégradation des performances ?
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Linux, pas prêt ?
Posté par Anonyme . Évalué à 5.
Ça donne que (dans ce cas là) les performances sont moins importantes que la sécurité.
[^] # Re: Linux, pas prêt ?
Posté par floriang . Évalué à -3.
6 mois d'embargo ?? 😱 🤢
[^] # Re: Linux, pas prêt ?
Posté par djano . Évalué à 1.
Il m'avait semblé lire que l'information était arrivée plus tard aux devs Linux. Pas de source, désolé.
[^] # Re: Linux, pas prêt ?
Posté par Albert_ . Évalué à 5.
A priori le timing d'apres LWN:
GKH dit que cela a ete gere comme une merde.
# Failles non-exploitées ?
Posté par gouttegd (site web personnel) . Évalué à 10.
En même temps, si l’exploitation de la faille ne laisse pas de traces, même en faisant « de gros efforts » on ne voit pas ce qui est invisible, alors sans aucunement remettre en cause le crédit des « personnes au courant », le fait est qu’on ne sait pas si les failles ont été exploitées.
Point de vue pessimiste : les failles ont été découvertes par plusieurs personnes indépendamment (au moins trois équipes différentes si j’ai bien suivi), donc on peut raisonnablement supposer qu’elles aient aussi pu être découvertes par d’autres acteurs.
Point de vue optimiste : les failles ont été découvertes par plusieurs personnes à peu près au même moment. Comme il est peu probable que toutes ces personnes aient toutes eu le même coup de génie au même moment, ces découvertes sont probablement l’évolution logique de travaux antérieurs. On peut donc selon moi tout aussi raisonnablement penser que si des acteurs mal-intentionnés ont eux aussi découvert ces failles, ils l’ont fait eux aussi à peu près au même moment (mi-2017 en gros), et donc que si ces failles sont exploitées elles ne le sont pas depuis longtemps.
[^] # Re: Failles non-exploitées ?
Posté par Olivier . Évalué à 4. Dernière modification le 05 janvier 2018 à 10:03.
Je me demande dans l’univers du hacking il y a des gens aussi motivés que les gens de la Scène pour “libérer” les failles de sécurité.
Ce matin, j’ai lu l’histoire du piratage de l’industrie musicale (et cinématographique). La motivation de ces gens a quand même de quoi étonner : https://www.newyorker.com/magazine/2015/04/27/the-man-who-broke-the-music-business
Si le monde du hacking a le même genre de types à leur service, alors ces histoires d’embargo sur les failles ne valent peut-être pas grand-chose.
[^] # Re: Failles non-exploitées ?
Posté par barmic . Évalué à 5.
hacking ou cracking ?
[^] # Re: Failles non-exploitées ?
Posté par djano . Évalué à 3.
Oui apparemment, des chercheurs ont creusé plus avant le concept (récent?) de side-channel attack sur CPUs. On peut s'attendre à se qu'ils trouvent de nouvelles attaques dans les mois qui viennent…
# On va enfin
Posté par Leniwce . Évalué à -10. Dernière modification le 05 janvier 2018 à 00:13.
se debarasser de cette architecture moisie x86 compatible Intel. Il etait temps de reprendre la ou l'innovation hardware c'est arrete, avec l'Amiga. On va enfin retrouver le choix des annees 90 au niveau processeurs et ordinateurs. Sans regret pour l'x86 et par la meme occasion si l'on pouvait se debarasser de windows ce sera la cerise sur le gateau.
attention chérie ça va moinsser
[^] # Re: On va enfin
Posté par xcomcmdr . Évalué à -3.
HAHAHA.
En 1991, le PC supplantait déjà l'Amiga, faut arrêter…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: On va enfin
Posté par Christophe B. (site web personnel) . Évalué à 9.
Oui mais pas au même tarif si je me souviens bien
Les mêmes caractéristiques coûtaient très cher sur PC si tu voulais approcher le niveau de l'Amiga
Oui l'Amiga fait partie de ces machines d'exceptions, mais terriblement propriétaire ne l'oublions pas …
Imaginez si à la place de Windows c'est MAC OS qui avait gagné …
[^] # Re: On va enfin
Posté par Michaël (site web personnel) . Évalué à 10.
C'est clair, en 1987 un Amiga 500+ coûtait 700 USD, avec 1 Mo de RAM, un lecteur de disquette 3 1/2, une puce motorola cadencée à plus de 7 Mhz, qui était capable de protéger les tâches, et flanqué d'une unité graphique rapide et programmable et d'une unité sonore descente. En comparaison, le Tandy 3000 HL coûtait environ 1500 USD (la numérisation de la pub est pas terrible, mais je crois arriver à bien lire!) avec une puce 286 (qui est incapable de protéger les tâches, ce qui n'est arrivé qu'avec le 386) pas d'unité sonore, une unité graphique bien inférieure à celle de l'Amiga et un lecteur 5 1/4… :) Si on ajoute la complexité de l'utilisation de MS-DOS en comparaison au Work-Bench de l'Amiga, la comparaison est douloureuse.
[^] # Re: On va enfin
Posté par Buf (Mastodon) . Évalué à 10.
L'Amiga 500 n'était pas capable de protéger les tâches, le 68000 n'ayant pas de MMU. Et le 286 en était bien capable, même s'il n'avait pas de MMU, en utilisant la segmentation et les tables de descripteurs locales (ce qui est loin d'être aussi efficace que ce permet le 386).
[^] # Re: On va enfin
Posté par Buf (Mastodon) . Évalué à 6. Dernière modification le 05 janvier 2018 à 14:07.
Précision : le 286 a quand même un MMU, mais sans fonctionnalité de mémoire virtuelle, qui est le mécanisme de base de protection de la mémoire des OS actuels.
[^] # Re: On va enfin
Posté par Christophe B. (site web personnel) . Évalué à 7.
??? je comprends pas le critère ou alors c'est trop technique pour moi …
L'amiga était une machine exceptionnelle (1987-88) ou l'on pouvait jouer, programmer (basic) et on disposait d'une interface graphique multi tache en avance sur tout le monde à l'époque
Avec en plus plein de logiciels sur des disquettes ( Fred Fish ) que l'on échangeait de la main à la main
Coté PC on parlait d'outil de travail … rien à voir
[^] # Re: On va enfin
Posté par Buf (Mastodon) . Évalué à 10. Dernière modification le 05 janvier 2018 à 16:37.
J'entends par là isoler l'espace mémoire utilisé par chacune des tâches. Sur un Amiga 500, un programme peut lire et écrire n'importe où en mémoire, y compris dans l'espace du noyau ou des autres tâches, et l'OS ne peut rien faire pour empêcher ça car le processeur ne possède pas le circuit de gestion de la mémoire requis (MMU).
Ça ne change rien au fait que l'Amiga était effectivement en avance sur son temps et son OS était un vrai multitâche préemptif, à l'époque où le reste des ordinateurs personnels étaient encore tous monotâches.
[^] # Re: On va enfin
Posté par Christophe B. (site web personnel) . Évalué à 6.
Merci d'avoir corrigé …
A cette époque l'informatique était surtout individuelle … et non connectée
D'ailleurs la propagation de virus se faisait via le boot secteur des disquettes … L'exterminateur de Lamer …
[^] # Re: On va enfin
Posté par Obsidian . Évalué à 5.
D'ailleurs, on dirait bien que les derniers lamers ont disparu avec les disquettes. Ils ont été remplacés par les noobs…
[^] # Re: On va enfin
Posté par Christophe B. (site web personnel) . Évalué à 3.
Les mêmes qui pullulent sous WOW ou LOL ?
[^] # Re: On va enfin
Posté par Obsidian . Évalué à 5.
Si ça pullule, il y a des chances que ce soit des Zerg mais globalement, c'est bien ça. ^
[^] # Re: On va enfin
Posté par Michaël (site web personnel) . Évalué à 5.
Merci pour cette correction, je me souvenais du contraire!
[^] # Re: On va enfin
Posté par GnunuX (site web personnel) . Évalué à 2.
heuuuu … c'est en contradiction avec "Ces deux failles sont liées à l’architecture des processeurs modernes (Intel, AMD, ARM, etc.)" non ?
[^] # Re: On va enfin
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Non mais c'est Leniwce. C'est juste un troll. Je serais même curieux de savoir s'il y a d'autres membres du site qui arrivent à poster à -4 par défaut.
La connaissance libre : https://zestedesavoir.com
[^] # Re: On va enfin
Posté par Michaël (site web personnel) . Évalué à 10. Dernière modification le 05 janvier 2018 à 12:20.
Je crois qu'il y en a un ou deux qui sont à -7. Ce qui en soit mérite le respect.
[^] # Re: On va enfin
Posté par reynum (site web personnel) . Évalué à 10.
Quelqu'un qui posterait à 7 mériterait le respect quelqu'un qui poste à -7 mérite le -respect :-)
kentoc'h mervel eget bezan saotred
[^] # Re: On va enfin
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
Ha ben apparemment on peut aussi poster d'office à -10. Ça mériterait presque une étude sociologique à ce niveau :D
La connaissance libre : https://zestedesavoir.com
[^] # Re: On va enfin
Posté par Marotte ⛧ . Évalué à 3.
Bah non, il a posté à -5, non ?
-5 + 2 - 7 = -10
Bon par contre, le compteur s’arrête à +10, je suppose qu’il en fait de même à -10…
[^] # Re: On va enfin
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
J'ai vu ses posts sans votes, je confirme qu'il poste bien à -10.
La connaissance libre : https://zestedesavoir.com
[^] # Re: On va enfin
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
La formule de la note par défaut est dans l'aide du site et la répartition du karma dans les statistiques sur les utilisateurs. Déjà il n'y a que 18 comptes actifs avec un karma négatif (parmi 2857).
# Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par azmeuk (site web personnel) . Évalué à 6.
Sur le principe, ça m'échappe. Comment est-ce que des processeurs de plusieurs conception différentes, qui ne partagent qu'un même jeu d'instructions peuvent-ils être touchés par la même faille ? A quel niveau se situe-t-elle ?
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Pinaraf . Évalué à 10.
C'est une faille sur l'"algorithme" implémenté (pardonnez moi cette simplification).
Un effet de bord n'a pas été pris en compte dans l'algorithme d'exécution prédictive, et donc "PAF"… Aucun fondeur n'a vu ce défaut avant, aussi étonnant que ça puisse paraitre.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par azmeuk (site web personnel) . Évalué à 4.
Si les différents fondeurs utilisent le même algorithme, j'imagine qu'il s'agit d'un algorithme assez connu et public. Par conséquent j'imagine qu'il est assez général, puisque les fondeurs ne doivent sans doute pas partager les optimisations qui les démarquent de la concurrence. J'ai juste ?
Malgré que l'embargo ne soit pas encore levé, connaît-on cet algo, et a-t-on compris la faille ?
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Pinaraf . Évalué à 10.
C'est pour ça que j'avais mis algorithme entre guillemets… :)
C'est effectivement très très général comme principe (ça colle mieux qu'algo).
Les processeurs modernes n'exécutent pas les instructions dans l'ordre, et tentent notamment de prédire quelles branches de code seront exécutées avant même d'interpréter la condition de la branche.
Par exemple :
Il est possible que dans le processeur b soit incrémenté alors que tableau[a] est supérieur à 73. En fait le CPU ne peut pas exécuter le code x86 dans l'ordre suffisamment vite pour atteindre son maximum d'utilisation, c'est juste impossible. Par exemple s'il exécutait ce code dans l'ordre, l'unité arithmétique dormirait la majeure partie du temps. Il vaut mieux qu'elle soit active et fasse une opération alors que l'on n'a pas encore exécuté la comparaison pour savoir si l'opération est requise. Au pire, on jette le résultat et on reprend les opérations depuis l'erreur. Au mieux, on aura le résultat à l'avance. Et là je parle bien d'optimisations réalisées par le CPU, pas par le compilateur.
C'est le principe d'une exécution «Out of Order» et d'une prédiction de branche.
Tu peux jouer avec la commande
perf statpour comprendre ça éventuellement plus concrêtement.Un CPU moderne est capable d'exécuter bien plus de 0,59 instructions par cycle (et je parle même pas de multi-cœurs). On voit qu'il a fait 5% de branch-misses, ce qui signifie qu'il a fait des mauvaises prédictions dans certains cas… Mais 5% c'est peu d'échecs et de temps perdu par rapport au gain qu'on a lorsqu'on a prédit avec succès…
Là où il y a un problème, c'est quand le processeur rejette un résultat. Ça laisse des traces. Et ça on n'y avait pas suffisamment pensé avant. L'attaque spectre consiste, en simplifié, à exploiter ces traces. De même pour l'attaque meltdown (mais qui profite en plus d'un bug d'intel qui vérifie des droits d'accès a posteriori et pas a priori (!))
Est-ce plus clair ?
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Michaël (site web personnel) . Évalué à 9.
C'est assez loin de mes préoccupations, mais si j'ai bien compris ce que j'ai lu, le principe est le suivant:
Il faut ce souvenir que les processeurs sont éloignés de la mémoire centrale et pour accéder à celle-ci rapidement, ils utilisent plusieurs niveau de cache. Le cache le plus rapide est dit de niveau L1, les autres caches sont plus lents, en enfin la mémoire centrale est la plus lente. En utilisant l'horloge interne du processeur pour estimer le nombre de cycles nécessaire à une opération de lecture, on peut deviner assez fiablement si une cellule mémoire est dans le cache L1 ou dans un autre système plus lent. L'astuce pour exploiter cette information consiste à écrire un programme du type
en s'arrangeant grâce à un saut conditionnel bien placé pour que l'approche spéculative du processeur lise la deuxième instruction et l'exécute avant de se rendre compte que l'accès à la mémoire dans la première instruction est interdit – car l'approche spéculative ne s'embrasse pas des règles de sécurité qui ne sont validées que lorsqu'on est sûr de la branche du programme qui doit être exécutée. L'état du processeur est rétablit… mais pas le cache: la vitesse à laquelle je peux lire dans la mémoire de mon processus me donne un petit indice sur la valeur de bx, alors qu'accéder à cette donnée est en principe interdit, car dans l'espace noyau.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par BlueDian . Évalué à 3.
C'est là où je ne comprend pas un truc : normalement la MMU bloque l’accès (même si c'est en lecture) à des pages interdites, je comprend pas comment le CPU peut éviter ainsi la MMU.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Pinaraf . Évalué à 7.
La MMU bloque l'accès… ou pas.
Que tu sois en espace noyau ou en espace utilisateur, tu es (avant KPTI) sur le même espace virtuel.
Ce n'est pas l'attaque actuelle, mais quand tu y réfléchis, d'un côté ton code est en ring 3, de l'autre en ring 0. Et c'est bien le CPU qui passe dans un mode ou un autre…
Le choix d'interdire ou non l'accès à une adresse ne dépend pas de la MMU. En "simplifié", la MMU sépare les différents process, mais comme historiquement on a noyau et process au même endroit, pim.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par BlueDian . Évalué à 10.
Re,
Je viens de comprendre grâce à wikipedia.
Meltdown utilise le fait que effectivement le micro-code peut faire l’accès à la mémoire avant que l'IT se déclenche (et interdise effectivement l'utilisation/visualisation de cette adresse), mais il la laisse qd même dans le cache (même si personne ne pourra en lire la valeur directement).
Mais le mal est fait car si on veut réutiliser cette adresse, le proc la prendra dans son cache et donc plus vite qu'une autre s'il devait aller la chercher en mémoire centrale.
L'astuce est d'utiliser cette adresse mémoire de manière détournée (dans un adressage indirecte par exemple).
On va dire pour mieux comprendre que l'on a droit de lire au-dessus de 0x500, mais pas entre 0x200 et 0x300. Et on veut pourtant connaître ce qui est contenue en 0x200 (supposons la valeur 10)
Il y a donc un premier programme qui va demander d'accéder par indirection à la mémoire en 0x500 + [la valeur contenue en mémoire 0x200]
Ce programme va être interrompu car on a pas le droit d'accéder en 0x200, mais il aura bien accéder à cette mémoire (en 0x510) et aura mis son contenu dans le cache…
Et ensuite un second programme qui lui va comparer les temps d’accès des mémoires de 0x500 à 0x600 (par exemple)
et par une mesure de leurs temps d’accès, on saura que l’accès à 0x510 est plus rapide, donc 0x200 contenait la valeur 10…
C'est le principe, bien sur il faut prendre en compte les tailles des pages and co…
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . Évalué à 10.
Pour ce que j'ai lu de la même page, c'est PRESQUE cela, en effet, mais à quelques détails près et qui feraient, entre autres, que l'approche par indexation en particulier ne pourrait justement pas marcher. Par ailleurs, tout repose sur le fait que l'on mesure un temps d'accès pour savoir si une donnée est ou non dans le cache. Et comme la réponse à cette question est forcément « oui » ou « non », ça implique de distiller l'info bit par bit, d'où l'exemple de la page Wikipédia et de son bit 0.
En gros :
La page précise qu'il vaut mieux éviter les branchement conditionnels pour faire ces calculs pour éviter de mettre en branle les mêmes mécanismes prédictifs (en gros, faire le calcul avec des opérateurs logiques plutôt qu'avec des « if »).
On se moque, en fait, de ce que contiennent les deux adresses légitimes mais toute l'astuce s'appuie sur le fait que la segfault va prendre un certain temps pour être déclenchée, et que les points 3, 4 et 5 auront le temps d'être honorés même si le CPU fait marche arrière ensuite si elle l'est. Après, sachant qu'on avait au départ vidé le cache, le point numéro 5 l'aura rechargé quand même. Donc, si l'une des pages est lente à accéder et que l'autre est rapide, on peut en déduire la valeur du bit recherché.
Évidemment, c'est très sioux et tout le problème réside dans le fait que ce n'est pas du tout un problème algorithmique. Tout microprocesseur doté d'un système de protection, d'un mécanisme de prédiction ET utilisant de la mémoire cache est potentiellement affecté.
On pourrait déjà circonvenir au problème en invalidant TOUT le cache en cas de segfault, mais on pourrait encore contourner la chose en faisant lire les adresses concernées par un thread ou un processus distinct qui, lui, n'aurait rien à se reprocher. Et qui pourrait presque le faire, en le synchronisant bien, avant le déclenchement de la segfault. C'est déjà compliqué à gérer en soi, mais ça devient particulièrement gênant sur les multicœurs et les systèmes distribués.
Et là où ça devient vraiment désespérant, c'est qu'apparemment la solution envisagée est : « puisque c'est une faille qui s'appuie sur la mesure des performances, alors on va sacrifier les performances ».
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par BlueDian . Évalué à 2.
Merci pour ce complément d'informations
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Naha (site web personnel) . Évalué à 7.
Je dis peut-être des bêtises, mais d'après ce que j'ai compris c'est justement ce qui fait que les processeurs AMD ne sont pas touchés par Meltdown : ils vérifient les permissions avant l'exécution spéculative, alors que les Intel le font tout à la fin, comme tu dis.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . Évalué à 6.
Je ne suis pas allé vérifier si c'est vrai ou faux, donc je ne me prononcerai pas sur le fond, mais si c'est le cas, alors à moins d'avoir une MMU extrêmement performante (ce qui est peut-être le cas aussi), alors cela mettrait complètement à mal l'exécution spéculative puisqu'elle serait obligée d'attendre sa décision avant d'être exécutée. Donc, ce ne serait plus de l'exécution spéculative. Et c'est un problème puisque cela concernerait TOUS les accès mémoire, aussi bien en lecture qu'en écriture, puisqu'il est par définition impossible de savoir si un accès est en dehors de sa plage avant de l'avoir examiné (sauf modes indexés spéciaux avec un offset notoirement local, parce que défini dans un petit registre (par exemple, sur 8 bits)). Donc, ce serait extrêmement fréquent dans un programme.
Reste à savoir si c'était quelque chose qui était réellement imaginable à l'avance, surtout au moment où les premières puces à pipeline ont été produites, puisque les rares qui sont encore en fonctionnement aujourd'hui sont menacées aussi. Autrement dit : est-ce vraiment une faute grave du constructeur compte tenu de son expérience et de son expertise, ou est-ce vraiment la faute à pas de chance ?
Parce qu'à ce compte-là, des compromissions de ce genre, on en a connu beaucoup dans le domaine logiciel mais, elles, peuvent être facilement patchées. Les générations de collisions pour MD5 et SHA1, par exemple, sont dans leur genre des petites bombes elles aussi et la dernière concernait particulièrement Git. Alors, certes, il « suffit » de passer à une nouvelle fonction de hachage pour pallier le problème jusqu'à ce qu'elle soit cassée à son tour, mais étant donné la diffusion du logiciel, il n'est pas concevable de réécrire toutes les sommes de tous les objets de tous les dépôts du monde, qui parfois contiennent des objets qui sont aussi vieux que Git lui-même, à commencer par le dépôt du noyau Linux. La seule solution consisterait à faire cohabiter les deux versions en marquant la première comme dépréciée.
Ici, c'est particulièrement grave parce que la faille se produit à très bas niveau, et a donc un impact très large en conséquence mais étant donné la complexification toujours plus forte des systèmes et le point auquel ils sont répandus, je pense qu'il va falloir s'attendre à faire face à ce genre d'incident à intervalles relativement régulier.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par moi1392 . Évalué à 3.
ça dépends, on peut très bien imaginer un bit de protection dans les entrée de la TLB (j'ai fait une petite recherche sur le web, mais je n'arrive pas à trouver de réponse)
Dans ce cas la, l'exécution prédictive peut juste s'arrêter si la TLB renvoie une page seulement accessible en ring 0 (et que l'on est en Ring 3)
Après, si la page accédée n'est pas dans la TLB, de toute façon ça va être (relativement) lent, donc la encore, ajouter un bit de vérification ne tuera pas les perfs je pense.
ça semble jouable, quelqu'un sait si ce genre de protection existe, et si oui, pourquoi elles ont merdé dans le cas présent ?
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Chuck #1 . Évalué à 2.
Je ne vois pas où est le problème de recalculer toutes les sommes de contrôle. C'est ce que fait Git à chaque fois qu'on clone un dépôt afin justement de vérifier qu'aucune version n'a été altérée.
Cette signature est publiée sous licence WTFPL
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . Évalué à 6.
Oui mais justement : on est censé retrouver les MÊMES sommes, et c'est entre autres ce qui permet de travailler de façon décentralisée sans avoir besoin de coordonnateur.
Changer de fonction de hachage n'altère en rien le fonctionnement théorique du logiciel (ce qui, en soi, est la marque d'une conception très bien pensée) et serait relativement facile à implémenter. Par contre, ce serait un cauchemar pour les administrateurs systèmes car cela implique de migrer l'intégralité des objets d'un dépôt ET d'amender tous les commits puisque ceux-ci contiennent en clair la somme de leur ou de leurs parents. On ne pourrait pas se contenter de les renommer, donc.
Ensuite, la grosse difficulté viendrait du fait que tout dépôt basé sur l'ancienne somme serait incompatible avec la nouvelle. Il n'y aurait donc pas de transition douce : tous les acteurs d'un même projet seraient donc d'abord obligés de mettre leur version de Git à jour, puis de migrer tous leur dépôts avant de pouvoir continuer à travailler ensemble. Et cela ne concernerait pas seulement les développeurs actifs : toute personne ayant cloné le noyau sur kernel.org serait concernée.
Enfin, cela rendrait caduques toutes les sommes publiées sous forme texte, que soit par mail, sur Usenet, sur le Web et sur les différents outils collaboratifs, que ce soit la LKML ou les commentaires des tickets Github. En outre, et par définition, les dépôts clonés cesseraient d'être des clones, puisqu'il pourrait y avoir plusieurs versions différentes d'un même objet : non seulement les sommes d'un commit serait différentes selon la fonction choisie, mais leur propre contenu le serait aussi puisqu'ils se référeraient à des sommes différentes. Il n'y aurait pour ainsi dire plus rien d'officiel pour indiquer facilement qu'ils sont les homologues de ceux calculés avec l'ancienne somme.
Le pire, c'est qu'il n'y aurait pas moyen de faire une conversion de l'ancienne somme vers la nouvelle a posteriori. Il faudrait dresser « pour l'histoire » une table de correspondance au moment où la migration se fait et ne surtout pas la perdre après cela.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Lucky Seven . Évalué à 10. Dernière modification le 05 janvier 2018 à 00:39.
Parce que les techniques d'optimisation sont les mêmes. Ici, c'est la prédiction des branches qui est attaquée.
Grosso-modo quand il y a un 'if' dans ton code, les processeurs n'attendent par que la condition du 'if' soit vérifiée pour exécuter le contenu du 'if', ils prennent de l'avance au cas ou le 'if' est vérifié. Le résultat est stocké dans le cache du processeur. Si le 'if' est finalement faux, ils ne vident pas le cache, ça serait trop couteux en performance.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par David Marec (site web personnel) . Évalué à 5.
Plus précisément, c'est un ensemble de défauts qui conduisent à la faille.
L'exécution en avance de phase du code ne serait pas un problème si elle n'avait pas aussi provoqué une mise en cache du résultat sur l'adresse pointée.
Les attaques sur le cache sont connues depuis plus longtemps.
# Merci pour la redirection…
Posté par Pinaraf . Évalué à 10.
Ben merci pour le commentaire sur mon journal…
Je vais tenter de faire une vulgarisation «grand public» des failles dans une émission de radio consacrée à l'informatique dans les prochains jours (l'Echo des Gnous, de chtinux)… Si ça se fait, sûrement ce dimanche ou dimanche prochain, je posterai ici un lien vers l'enregistrement.
[^] # Re: Merci pour la redirection…
Posté par Pinaraf . Évalué à 10.
Je confirme, ce dimanche de 19H à 20H sur radio campus lille, dans l'echo des gnous, nous allons tenter d'expliquer tout ce bazar en des termes compatibles grand public.
Ceux qui ont compris les journaux et dépêches sur ce sujet n'apprendront probablement pas grand chose. Les autres peuvent s'en servir pour répondre à des questions…
Il sera donc possible d'écouter en live sur http://campuslille.com/ dimanche (et on sera joignables sur IRC, #chtinux sur freenode), ou en différé par le podcast https://podcast.grossard.fr/ (Merci encore au mainteneur du podcast, si tu lis ceci…)
[^] # Re: Merci pour la redirection…
Posté par \o/ . Évalué à 3.
Et merci à toi!
[^] # Re: Merci pour la redirection…
Posté par Skilgannon . Évalué à 0.
Yep Merci.
Merci Pinaraf pour le journal initial et merci aux autres pour leurs commentaires (contructifs).
Je lis l'anglais quand c'est nécessaire (quand je recherche quelque chose par exemple) mais là au vu du sujet qui est un peu trop velu pour moi j'avoue que j'ai même pas essayé. Donc merci pour les commentaires de m'avoir éclairé sur le sujet. **
** Ça m'a même rappelé quelques trucs qu'un prof a tenté de m'inculquer il y a quelques années…
# Mise à jour Debian pour Meltdown sortie
Posté par Olivier Esver (site web personnel) . Évalué à 7. Dernière modification le 05 janvier 2018 à 01:05.
La mises à jour pour la faille intel est sortie :
https://lists.debian.org/debian-security-announce/2018/msg00000.html
Les autres failles bientôt
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par Wawet76 (site web personnel) . Évalué à 2.
Apparemment, il faut faire un "apt-get dist-upgrade" pour que le paquet soit mis à jour.
Quelqu'un sait pourquoi ? Il me semble avoir déjà eu le noyau mis a jour par un simple "apt-get upgrade"…
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par François GUÉRIN (Mastodon) . Évalué à 1.
Salut,
Un:
$ sudo apt update && sudo apt upgrade
semble faire le taff : linux 4.14 dans les mises à jour…
linux-image-amd64 amd64 4.14+88
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par Wawet76 (site web personnel) . Évalué à 1.
Sur Stretch c'est Linux 4.9, et j'ai du faire dist-upgrade sur 3 machine différentes.
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par gpe . Évalué à 1.
Moi j'ai du l'installer manuellement. Le upgrade ou dist-upgrade ne faisait rien.
Sur Sid le noyau corrigé (4.14.12-2) semble poser problème:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886474
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886506
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par Cyril Brulebois (site web personnel) . Évalué à 9.
Un
apt-get upgradesuffit si l'ensemble de paquets avant/après est le même. C'est usuellement le cas dansstable(mais coucoubind9qui change ses SONAME régulièrement, et les noms de bibliothèques sont changés en conséquence).Cependant, on a déjà vu des mises à jour de noyau qui changent l'ABI : cf. sortie de
uname -r, c'est ce que l'on retrouve aprèslinux-image-dans le nom du paquet binaire.Ici, on passe de
(linux-image-)4.9.0-4-amd64à(linux-image-)4.9.0-5-amd64, donc la simple mise à jour du méta-paquetlinux-image-amd64ne suffit pas : il tire une nouvelle dépendance (la version en -5), il faut donc undist-upgrade.Debian Consultant @ DEBAMAX
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par sebas . Évalué à 2.
ou alors, si on ne veut pas faire un dist-upgrade, il suffit de faire un
apt-get install linux-image-amd64 linux-headers-amd64
qui va chercher le noyau 4.9.0.5 et toutes les dépendances qui vont avec.
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par Marc Quinton . Évalué à 3.
c'est moi, ou ca a l'air partiellement corrigé sur Debian : https://security-tracker.debian.org/tracker/source-package/linux
- CVE-2017-5754
- CVE-2017-5753
- CVE-2017-5715
[^] # Re: Mise à jour Debian pour Meltdown sortie
Posté par Anonyme . Évalué à 2.
Faut pas compter la dessus, la seule correction à Spectre est le changement de matériel.
# Précisions / corrections
Posté par Guillaume Knispel . Évalué à 10.
Meltdown et Spectre permettent de lire les données de divers espaces d'adressage.
Pour Meltdown, c'est le noyau, et ça suffit pcq sous Linux ya toute la mémoire du système mappée pour lui. Pour Spectre, c'est aussi le noyau sauf s'il intègre des contres mesures spécifiques (à au moins 2 variantes connues de Spectre, on en trouvera ptet d'autres plus tard), et plus généralement si le noyau est protégé, tout processus n'intégrant pas de contre-mesures et avec lequel on peut interagir un minimum. C'est "un peu" gênant pour les navigateurs Web pcq'ils JIT le JS vers du code natif…
Pour certaines des contremesures, des patchs GCC / LLVM sont en préparation. Jusqu'à 50% de perfs en moins sur du C++ rempli de vtable et pas optimisé… :/ (et le premier qui me sort que c'est pas grave on peut faire du LTO et de la dévirtualisation, je l'étrangle à coups d'undefined behaviors)
Vous pouvez être sûr qu'on a pas fini d'en entendre parler et que l'imagination va déborder pour trouver d'autres vecteurs.
[^] # Re: Précisions / corrections
Posté par Firwen (site web personnel) . Évalué à 2.
Et ça reste du C++…. Sur des languages fortement Objet ou les appels se font presque tous par vtables / déférencement, ça va être popcorn time.
[^] # Re: Précisions / corrections
Posté par Nitchevo (site web personnel) . Évalué à 3.
Bon si le pc se traîne il suffira d'en changer….
# Meltdown, seulement Intel ?
Posté par David Marec (site web personnel) . Évalué à 8.
Je reprend un commentaire écrit dans le journal,
les auteurs de l'article qui décrit Meltdown n'ont pas aussi clairement affranchi
les autres fondeurs de la faille.
Ils expliquent seulement que leur «POC», qu'il appellent «toy» et basé sur une attaque de cache de type
Flush+Reload, n'a pasobtenu de résultat.
Seulement, leur mesures semblent indiquer que le problème existe là aussi.
L’exécution d'un accès non autorisé aurait bien eu lieu sur les autres architectures, ils n'ont pas contre par réussi à sortir le résultat d'un cache.
[^] # Re: Meltdown, seulement Intel ?
Posté par Guillaume Knispel . Évalué à 7.
AMD a indiqué sur la LKML que leurs processeurs ne chargent jamais les données d'un niveau de privilège élevé vers un plus faible, même lors d'une exécution spéculative. Ils sont donc à priori immunisés contre Meltdown tel qu'il a été défini. Maintenant ptet qu'on imaginera des variantes entre Meltdown et Spectre…
[^] # Re: Meltdown, seulement Intel ?
Posté par David Marec (site web personnel) . Évalué à 5.
La réponse officielle est là:
En effet, AMD insiste sur le fait que la variante 3 (Meltdown) ne les concernent pas. Enfin, AMD prétendait ne pas être concerné du tout il y a peu.
Celle d'ARM:
Là il existerait une variante de Meltdown qui permette d'utiliser la faille.
[^] # Re: Meltdown, seulement Intel ?
Posté par jeberger (site web personnel) . Évalué à 10.
En fait l'article décrit trois attaques :
La première touche absolument tous les processeurs modernes quel que soit le fabriquant (y compris probablement les OpenMIPS et OpenSPARC bien qu'ils ne soient pas cités) et permet à un processus d'accéder à sa propre mémoire. Alors pourquoi est-ce un problème (et pourquoi le processus ferait-il comme ça plutôt que d'accéder directement à la mémoire) ? Tout simplement parce qu'un script tournant sur une VM (de type VM javascript) peut exploiter la faille pour lire n'importe où dans la mémoire du processus (donc par exemple dans la mémoire concernant les autres onglets du navigateur). Noter à ce sujet que le noyau Linux contient une VM (eBPF) utilisée à l'origine pour les pare-feux et qui permet à n'importe quel programme d'exécuter un script en espace noyau et donc de lire toute la mémoire du noyau (à un rythme de 1500 octets/s environ). Cette attaque devrait pouvoir être patchée au niveau logiciel dans les VM avec un coût relativement faible.
La deuxième attaque n'a été démontrée que sur les processeurs Intel, mais ARM reconnaît que ses processeurs sont aussi vulnérables. AMD prétend que les siens ne sont pas touchés (plus exactement AMD dit que personne n'a montré que cette faille touche leurs processeurs, mais rien ne prouve qu'ils sont immunisés). Cette faille demande une connaissance très poussée de l'unité de prédiction de branchement du CPU (que les auteurs ont obtenue par rétro-ingénierie sur les processeurs Intel) ainsi que du code de l'OS ou de l'hyperviseur cible. L'attaque permet d'injecter du code dans le contexte de l'OS ou de l'hyperviseur. Elle fonctionne en trompant l'unité de prédiction de branchement pour que celle-ci fasse exécuter du code choisi par l'attaquant au moment où l'OS cible fait un branchement conditionnel. Le résultat de ce code sera jeté quand le CPU s’apercevra de l'erreur de prédiction, mais des effets secondaires peuvent rester visibles (en particulier le chargement de données en cache). Je n'ai pas entendu parler de correctif pour cette attaque…
La troisième attaque ne concernerait que les processeurs Intel et vient du fait que la MMU contrôle l'accès a posteriori. Elle permet à un processus de lire une page mémoire qui est présente dans son espace d'adressage, même si la lecture de cette page est normalement interdite. Elle ne permet pas en revanche de lire une page mémoire non présente dans l'espace d'adressage. La raison pour laquelle cette attaque pose problème c'est qu'une grande partie de la mémoire des OS est présente dans l'espace d'adressage des applications en mode lecture interdite (en tout cas pour Linux et Windows) afin d'accélérer les appels systèmes (il est beaucoup plus rapide de changer les permissions d'une page existante que d'ajouter ou de supprimer des pages dans la MMU). Les patchs du noyau Linux dont on parle visent à retirer la mémoire de l'OS de l'espace d'adressage des applications, ce qui bloquera cette attaque mais augmente considérablement le coût des appels système (jusqu'à 60% de perte de performance sur des benchmarks synthétiques, PostgresSQL a été mesuré à -17% quand ces patchs sont activés).
[^] # Re: Meltdown, seulement Intel ?
Posté par Guillaume Knispel . Évalué à 5. Dernière modification le 05 janvier 2018 à 19:57.
Les deux première sont nommées Spectre, et la dernière Meltdown.
Le problème c'est que l'idée générale de la première attaque pourrait potentiellement être déclinée en plein de nouvelles autres attaques similaires. Le second problème c'est que les patchs en cours de réalisation sont des mitigations posées pour certaines manuellement à des endroits que l'ont considère aujourd'hui comme particulièrement sensibles.
Enfin d'autres patchs en cours de développement sont des mitigations contre la variante 2, et cela inclut de nouvelles manières pour les compilateurs d'émettre du code correspondant à certaines constructions. Cela pourrait plus ou moins ralentir de nombreux programmes dans divers langages de prog (selon les programmes, et selon la manière dont on les compile)
Le seul vrai fix pour Spectre qui comblera beaucoup mieux la faille, et sans trop sacrifier les performances, sera de changer assez radicalement la micro-architecture interne de futurs processeurs.
Meltdown nécessite aussi de fixer le hard des fondeurs concernés histoire de pas sacrifier les performances, mais le fix devrait être relativement simple. Reste qu'Intel n'a pour l'instant que les procs les plus touchés, et c'est même pas sûr que les prochains qu'il va sortir ne fixeront ne serait-ce que Meltdown. On peut toujours se rabattre sur AMD en attendant (ou durablement), avec son archi Zen qui devient encore plus intéressante…
[^] # Re: Meltdown, seulement Intel ?
Posté par reno . Évalué à 2.
Je pense que le problème n'est pas seulement pour un interpréteur: ça remet en cause la sécurité par capabilities non?
# Et Linus ?
Posté par .Nicolas. . Évalué à -8.
Il me semble qu'il y avait eu une histoire sur le respect ou non de l'embargo chez BSD ?
J'ai eu confirmation que c'est bien Linus qui a dévoilé la faille le premier en poussant les patchs avant terme.
C'est donc bien lui qui est mis en cause dans le communiqué Intel. Auquel il a répondu très hypocritement par ailleurs…
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
https://www.numerama.com/tech/318658-linus-torvalds-nest-vraiment-pas-convaincu-par-la-communication-dintel-sur-meltdown.html
C'est que le problème affecte potentiellement tout le monde mais ça n'a pas empêché la concurrence de claironner le contraire…
Vu l'impact que ça risque d'avoir sur son activité, Intel va garder rancune de cette affaire. Ce n'est pas très malin de se mettre à dos un fondeur aussi important et aussi bêtement.
Ce genre de blague sont préjudiciables à la sécurité future du noyau.
[^] # Re: Et Linus ?
Posté par Firwen (site web personnel) . Évalué à 10. Dernière modification le 05 janvier 2018 à 13:28.
J'aurai tendance à dire que Linus a entièrement raison.
"""
I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.
… and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.
Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything?"""
La réponse d'Intel s'approche presque d'un foutage de gueule en choisissant bien sagement ses mots.
Un processeur qui autorise un programme parfaitement conforme à leaké ses données en violant complètement la protection mémoire, même indirectement, est un processeur buggé, n'en déplaise à Intel.
La pire faille du lot est bien Meltdown, et c'est principalement les processeurs Intel qui sont touchés, pas la concurrence.
[^] # Re: Et Linus ?
Posté par flagos . Évalué à 6. Dernière modification le 05 janvier 2018 à 14:43.
Le plus désolant dans tout ca, c'est que même avec 6 mois d'embargo, ils ont manifestement une communication faite dans l'urgence. On se demande presque a quoi ca sert d'avoir des embargos si long si au final ca sert a avoir le temps de choisir un logo et un nom sympa pour la faille…
[^] # Re: Et Linus ?
Posté par claudex . Évalué à 10.
Au final, on a pu avoir un patch à temps (presque) pour Linux, Windows et MacOS. Du coup, ça vaut la peine.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et Linus ?
Posté par Guillaume Knispel . Évalué à 5.
Ça se pourrait que leurs communicants n'aient pas été prévenus tout de suite, afin de limiter le risque de fuites. Ceci étant dit 1 semaine avant la deadline, ça reste curieux.
[^] # Re: Et Linus ?
Posté par gouttegd (site web personnel) . Évalué à 10.
D’après le dernier article d’Ars Technica, c’est un développeur AMD qui a mis la puce à l’oreille de tout le monde en postant le patch qui désactive la mitigation pour les processeurs AMD (et dont le commentaire était un peu trop bavard).
# Mais que fait la p̶o̶l̶i̶c̶e̶ MMU ?
Posté par trancheX . Évalué à 2.
Donc si je résume un max le problème :
1. pour des raisons de performance les OS font des entorses à la séparation mémoire kernel/userspace permise par la MMU pour des raisons de performance et les processeurs implémentent des "optimisations" pour faciliter cela.
2. certaine ""optimisations"" s'accompagnent de 2 types de failles de sécurité : une grossière (Meltdown concerne intel seulement) et une pernicieuse (Spectre concerne intel, ARM, AMD).
3. Ces failles se situant niveau hardware, l'OS ne peut pas les corriger "proprement".
J'avoue que en regardant les explications de comment est utilisé/partagé la mémoire kernel/userspace je ne comprends plus trop : la MMU ne joue plus le rôle de gardien du tout ?
Parce que normalement la MMU devrait empêcher complétement qu'un processus puisse aller voir la mémoire du kernel ou celle d'un autre processus.
[^] # Re: Mais que fait la p̶o̶l̶i̶c̶e̶ MMU ?
Posté par Pinaraf . Évalué à 10.
Alors…
1) c'est une entorse protégée par le "contrat" entre les développeurs et le CPU. La mémoire noyau est vendue par l'architecture comme intouchable avec ce découpage.
2) meltdown est une violation du contrat précédent. Spectre par contre c'est autre chose, une optimisation qui permet de dévoiler des données
La MMU continue en tout cas son boulot de gardien, comme toujours : la mémoire virtuelle A n'a pas accès à la mémoire virtuelle B. Mais le processeur reste maitre de l'accès aux pages virtuelles. Si il dit qu'il peut lire la mémoire du noyau, il peut. Même si c'est un mensonge, qu'il est en ring 3 et que c'est de la mémoire "réservée" au ring 0… Et tout ça c'est meltdown.
[^] # Re: Mais que fait la p̶o̶l̶i̶c̶e̶ MMU ?
Posté par trancheX . Évalué à 2.
1/ OK pour l'entorse, ce n'étais absolument pas une critique de ma part. J'avoue que je ne pensais pas que cela fonctionnait comme ça et je croyais vraiment que la MMU était un truc imparable dans tous les cas.
Pour spectre je ne comprenais pas comment un process pouvait aller voir les pipelines d'instruction d'un autre process.
En fait j'avais le même problème de compréhension que BlueDian, grâce aux autre commentaires c'est plus clair (merci Pinarf, BlueDian et Obsidian je vais me coucher moins bête).
Spectre est particulièrement sioux et si j'ai bien compris le kernel ne peut absolument rien y faire : ça va être aux compilateurs de faire autrement pour ne pas générer de code "prédictible" … avec les perfs en moins qui vont avec (Note: le patch llvm est assez bien expliqué et compréhensible après avoir lu ce qu'est l'instruction RET).
Et je supposes que tout les langages qui font du JIT (je penses surtout à javascript et aux navigateurs, mais hotspot) vont devoir faire de même ?
[^] # Re: Mais que fait la p̶o̶l̶i̶c̶e̶ MMU ?
Posté par Guillaume Knispel . Évalué à 10. Dernière modification le 05 janvier 2018 à 16:43.
Chez Intel, la manière dont les infos fournies par la MMU sont exploitées par d'autres bouts du CPU est en effet clairement défaillante (même si le fondeur n’arrête pas de répéter que tout fonctionne comme conçu, ce qui veut dire que c'est leur conception qui est clairement moisie et bugué): les données d'un privilège élevé sont chargées spéculativement pour du code d'un niveau de privilège plus bas, et en plus de ça l'exécution spéculative continue y compris en produisant des effets de bord micro-architecturaux flagrant.
Pour Spectre, c'est clairement un truc malin auquel personne n'avait pensé intégralement auparavant (du moins sans le signaler). En choisissant bien les données contrôlées par un niveau de privilège inférieur/un contexte ne devant pas avoir accès à d'autre données, et utilisées par du code ayant l'accès (par exemple en jouant sur les paramètres d'un appel système), il est possible de pousser le code privilégié à réaliser des exécutions spéculatives complètement délirantes, et ensuite en mesurant les effets de bord microarchitecturaux, d'en déduire des données ciblés. Mais il faut trouver des bouts de code dans les programmes existant qui prévoient des opérations pouvant être ainsi détournées. Ce qui est beau dans cette dernière attaque c'est que le code source du programme ciblé a beau être parfaitement correct, ça ne change rien, car les processeurs en régime spéculatif passent outre les vérifications programmées classiquement pour tenter de prendre de l'avance sur la suite du boulot. C'est cette anticipation qui, selon les cas, change suffisamment l'état interne du processeur d'une manière dépendant des données lues, et mesurable.
Dans le cas de Meltdown il n'y a pas de code tiers privilégié qui effectue les accès pour le compte de l'attaquant: c'est le CPU qui est à moitié con.
# Processeur LISP
Posté par lecrocodile . Évalué à -10.
Bonjour, j'ai juste une remarque à faire, si à la place des processeurs actuel on utilisé les processeurs lisp, avec les schéma des architectures(des processeurs en question) alors les gens pourraient les améliorer et utiliser uniquement des logiciels libre car je cite Wikipedia "Les machines Lisp sont des ordinateurs conçus pour interpréter Lisp efficacement et nativement".
PS: C'EST PAS UN TROLL, MAIS CEST SéRIEUX.
[^] # Re: Processeur LISP
Posté par dguihal . Évalué à 6.
Tu veux vraiment dire SÉRIEUX de chez SÉRIEUX ? Ou alors c'est juste SÉRIEUX ?
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Cool mec j'ai déja fais un post et c'est parti dans tous les sens donc cool, tranquille zen.
[^] # Re: Processeur LISP
Posté par totof2000 . Évalué à 5.
Et pourquoi pas un processeur java ?
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Si on utilise un processeur JAVA il est possible de faire autre chose que d'utiliser du logiciel libre avec.
[^] # Re: Processeur LISP
Posté par totof2000 . Évalué à 5.
???? Pourquoi et comment voudrais-tu empêcher d'exécuter du code non libre sur un processeur ?
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Comment faire je ne sais pas, pourquoi ? C'est simple un code source c'est du savoir écrit d'une façon particulière mais du savoir quand même, je pense que tout savoir doit être partagé, c'est comme ça que l'humanité a évolué au court des siècles et aussi car je suis français et très attaché aux valeurs de liberté, d'égalité et de fraternité. C'est pour ça que je veux que les logiciels privateur meurent sauf dans le cas particulier des jeux vidéo.
[^] # Re: Processeur LISP
Posté par Anonyme . Évalué à 9.
Sur une machine lisp aussi, suffit de ne pas partager librement son code. Puis comme on peut le voir dans l'informatique actuelle, on peut avoir un OS open-source avec des modules propriétaires, même la GPL le permet. Enfin, il y a des boites qui s'en tapent et qui repompent du code GPL dans leur blob comme si c'était du BSD.
Pourtant avec la phrase précédente, tu sous-entends que ce n'est pas possible de le faire sur une machine lisp pour balayer l'idée de la machine java. Tu manques de cohérence.
Ah bon pourquoi une exception ? Que tu considères le JV comme un art ou comme un divertissement il n'y a aucune raison que ce type de logiciel en particulier soit épargné, c'est aussi du savoir.
Ça faciliterait énormément la portabilité et la maintenabilité au fur et à mesure de l'évolution de l'informatique plutôt que se taper les DLC, les émulateurs, machines virtuelles et interpréteurs, les libs i386 en doublon, les jeux codés à l'arrache qui respectent pas les API graphiques et nécessitent des profils particuliers dans les pilotes de CG, les bugs foireux pas MÀJ, etc.
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Comme les processeurs Lisp lisent nativement le LISP plus besoin d'utiliser un autre langage de programmation et plus besoin de compilateur puisque c'est le processeur qui s'en charge donc c'est difficile d'utiliser du code non LIBRE.
Les jeux vidéo c'est un peu comme un film d'animation(pour les cinématiques) et des créateurs(artistes ?) qui font la musique et eux doivent pouvoir protéger leurs œuvres. Pour les développeurs eux ils devraient dans un monde "bisounours" recevoir un salaire des états qui seraient payé par une partie de l'impot car les dev libre contribuent au bien commun selon moi.
[^] # Re: Processeur LISP
Posté par claudex . Évalué à 6.
C'est donc le compilateur qui rend le code non libre, si on avait su depuis tout ce temps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Processeur LISP
Posté par Anonyme . Évalué à 3.
Non c'est simple : je fourni un programme et je fous des restrictions dessus (accord de non-divulgation, restriction de l'utilisation, interdiction de modification) et si tu les respectent pas je t'attaque en justice.
Tu confonds licence libre et sources partagées.
En quoi c'est différent par rapport à faire un logo, une image, une charte graphique, des éléments sonores ou une composition intuitive des éléments affichés à l'écran pour un autre type de logiciel ?
Et où places-tu la limite entre programme et JV ? Est-ce qu'un mod manager ou un launcher font partie du jeu ? Est-ce que l'éditeur de niveau inclus dans le binaire n'est pas en soi un logiciel distinct du jeu en lui-même ? Est-ce que le serveur pour du multijoueur fait partie du jeu ? est-ce que le moteur de jeu est inclus dans ta définition ?
Si le manuel d'utilisation ou le tutoriel d'un logiciel "sérieux" est écrit en alexandrins, est-ce que ça compte pour pouvoir "protéger son œuvre" ?
L'art libre ainsi que l'art non-commercial existent déjà, regarde les journaux et dépêches ici-même pour en avoir un aperçu.
Certes mais en quoi ça diffère du JV ? Pourquoi ne pas vouloir appliquer ton principe marxiste à tous les artistes ? Et comme tu le sous-entends, en quoi l'art et le divertissement ne participeraient pas au bien commun ?
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Pour un JV tout ce qui relève de l'art est tout ce dont on peu admirer la beauté en utilisant juste ses sens le reste étant de la technique qui elle n'est pas accessible aux novices. J'ai du mal à voir en quoi un JV participe au bien commun, cela n'est pas vital dans notre monde moderne.
Tu parle de principe marxiste, peut être j'ai pas lu Karl Marx mais je suis pour le salaire de subsistance qui permétrait au gens de de vivre et de s’épanouir dans des domaines qu'ils aiment.
[^] # Re: Processeur LISP
Posté par Anonyme . Évalué à 4. Dernière modification le 07 janvier 2018 à 23:25.
Déjà, il y a plein de choses culturelles ou symboliques plus ou moins cachées dans les œuvres d'art donc ça n'utilise pas que les sens mais aussi l'intellect et la mémoire et tout le message n'est pas accessible par le novice. L'art n'est pas universel.
Ensuite, la technique elle-même a une forme de beauté, de sensibilité et tout ce qui différencie l'artisanat de l'art au niveau législatif (et surtout fiscal) c'est le fait de produire quelque chose qui a de l'utilité autre qu'esthétique.
Toute production artistique demande avant tout du savoir technique.
La plupart des activités humaines ne sont plus vitales de nos jours.
Le bien commun c'est aussi la culture et le savoir, le JV est utilisé à des fins pédagogiques, éducatives, thérapeutiques et expérimentales dans divers domaines, en quoi ces outils sont différents des outils classiques pour mériter d'être exclus du bien commun ?
Donc, encore une fois, pourquoi exclure la création de jeu vidéo et par extension le domaine artistique et le divertissement ? C'est pas cohérent. L'humain a de plus en plus de temps libre pour faire autre chose que produire de l'utile.
[^] # Re: Processeur LISP
Posté par Zenitram (site web personnel) . Évalué à 2.
Incompatible avec ton "sauf" plus loin.
Le premier à qui tu mens est toi-même.
Et les non-français ne méritent pas d'avoir les mêmes principes que toi, il faut être français pour?
tiens, ça faisait longtemps le coup de "je suis contre la peine de mort sauf quand je veux l'appliquer".
--> "très attaché aux valeurs de liberté, d'égalité et de fraternité, sauf quand ces valeurs me font chier" donc. Rien de neuf.
Résumé : tu n'es attaché à rien, à part peut-être à l'opportunisme.
Sinon, ce que tu appelles "cas particulier" est tout aussi légitimes dans d'autres domaines qui ne te plaisent pas autant sans pour autant trahir les mots "liberté, d'égalité et de fraternité", et c'est pour ça que le libre et le non libre peuvent coexister malgré l'intégrisme religieux de certains.
Oups, désolé
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Les jeux vidéo ne sont pas que du savoir, il y a de la création artistique pure(cinématiques, bande son).
Je dois définir ce que c'est être Français selon moi. C'est aimer les valeurs que j'ai cité plus haut. Après les papiers c'est rien car je pense qu'on ne nais pas Français mais on le devient, pour moi Richard STALLMAN est Français.
[^] # Re: Processeur LISP
Posté par totof2000 . Évalué à 5.
Ah, donc pour toi, le livre n'est que du savoir parce qu'il n'y a ni mouvement, ni son ?
Et pourquoi ne pas considérer le code comme un art, tout comme on considère la littérature comme un art ?
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Je faisais pas référence aux jeux ou il n'y a que du texte qui est évidement de l'art par ex les bouquins de Robert Erwin Howard que j'adore. La grande différence entre le code et les autre domaine artistique c'est qu'il faut avoir avoir des bases pour bien comprendre sa beauté alors que dans les autres cas seuls nos sens sont utilisés.
[^] # Re: Processeur LISP
Posté par totof2000 . Évalué à 3.
Et pourquoi dans ce cas un processeur LISP et pas un processeur JAVA ?
Et dans ce cas pourquoi plus Lisp que Java ?
[^] # Re: Processeur LISP
Posté par lecrocodile . Évalué à -10.
Je penche vers LISP car avec peu d'instruction on peut faire beaucoup de chose même si il faut répéter souvent les même instructions. Java est beaucoup plus complexe.
[^] # Re: Processeur LISP
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Si on utilise un processeur LISP il est possible de faire autre chose que d'utiliser du logiciel libre avec.
# uBlock Origin ou NoScript ou uMatrix.
Posté par Anonyme . Évalué à -1.
Le mec qui a fait uBlock Origin, un certain Raymond Hill, a également fait uMatrix, une super extension pour gérer cookie / css / images / javascript et autres joyeusetés.
# OpenBSD
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 06 janvier 2018 à 11:06.
Première réaction officielle des devs d'OpenBSD sous la forme d'un mail de Philip Guenther sur la liste de diffusion : https://www.mail-archive.com/tech@openbsd.org/msg43791.html
Donc ça confirme ce qu'on soupçonnait déjà c'est à dire que les devs OpenBSD n'étaient pas dans le secret de l'existence de ces failles, qu'ils n'ont donc pas pu bosser sur un correctif du type KPTI (qui corrige Meltdown). Aucune solution n'est actuellement disponible sous OpenBSD et la faille Meltdown est grande ouverte :-(
Et aucune info n'est donnée dans ce post au sujet de Spectre ou d'une solution type Retpoline ou IBRS.
C'est la méga merde….
[^] # Re: OpenBSD
Posté par Zenitram (site web personnel) . Évalué à 3.
Pourquoi? Si les gens utilisent cet OS, qui est peu utilisé donc choisi "activement" (et non parce que les autres ont choisi), ils savent bien la philosophie à propos des embargos et agissent en conséquence, non?
Bon, ici les autres *BSD n'ont été prévenus mais à ma connaissance il n'y a pas d'engagement non plus de la part des autres *BSD à respecter les embargos et/ou à avoir un groupe dessus (car l'addition de tous les *BSD c'est bien moindre que Linux, alors faudrait déjà se montrer en groupe) et un engagement à éviter une réaction type Theo de Raadt (voir sa réponse au lien) à insulter plutôt que de se demander comment être prévenu en avance la prochaine fois.
Bref, ici on a un résultat voulu par des choix clairs aux conséquences claires sans aucune remise en cause de ces choix, donc pas possible que ce soit une méga merde… Juste le résultat que tu peux attendre de cet OS.
[^] # Re: OpenBSD
Posté par bubar🦥 (site web personnel) . Évalué à 7.
C'est faux, FreeBSD a été prévenu, tardivement à la mi-décembre, mais a bien été prévenu, voir ici
[^] # Re: OpenBSD
Posté par anaseto (site web personnel) . Évalué à 10.
Oui, enfin, “late December” pour un embargo de six mois, qui a en plus été écourté d'une semaine à la fin suite aux déductions de la communauté par rapport aux patches appliqués dans Linux (qui même sans le patch bavard du gars d'AMD étaient très curieux pour une rc6), c'est pas vraiment être prévenu, ils en sont au même stade que les autres (voire en retard par rapport à DragonFly).
[^] # Re: OpenBSD
Posté par Guillaume Knispel . Évalué à 10. Dernière modification le 07 janvier 2018 à 00:40.
J'abonde qu'on aurait probablement trouvé Meltdown même sans le commit message d'AMD. Il n'y a pas 36 raisons de vouloir démapper tout le kernel space en urgence, dans tous les OS (et non, le simple cassage de KASLR n'en est pas une très bonne…). Justement l'intégration sous l'upstream Linux a été mal organisée s'il y a vraiment eu une volonté correctement pensée de discrétion. Les distros "commerciales" avaient déjà des patchs "secrets" couvrant y compris Spectre (avec du code venant d'Intel, qui semble être globalement le même qui a été intégré à Windows), alors qu'au moins GregKH ne semblait pas au courant de tout (et probablement même Linus… vu ses réactions et ses propositions récentes à la lecture des propositions de mitigations de Spectre). Il semblerait même que le développement secret pour les distros commerciales se soit fait en silo, sans trop de communication entre elles…
Ça aurait ptet moins choqué les observateurs si KPTI avait été intégré bien plus tôt dans le cycle, et simplement activé par défaut au dernier moment de la fin de l'embargo (avec une sortie rapide du premier backport), mais bon ya pas d'alignement de ce calendrier avec le patch Tuesday de MS sauf à avancer ou retarder d'un mois ou plus (même si au final ça c'est terminé par une MAJ hors calendrier côté MS, donc bon, Linux aurait du primer, ça aurait mieux fonctionné). Bon ceci étant Linus avait déjà un peu vendu la mèche en prévenant qu'il pensait que ça allait être backporté sur tous les noyaux LTS.
Il semblerait que les projets concernant Linux ont été au moins depuis fin août/début septembre de ne publier sur la LKML les premiers patchs pour Spectre qu'à la fin de l'embargo. Du coup, son arrêt précipité est une bonne nouvelle; on aura des mitigations officielles pour le vrai Linux sans doute un peu plus tôt, et un peu mieux conçues.
[^] # Re: OpenBSD
Posté par anaseto (site web personnel) . Évalué à 9.
Les autres BSDs n'ont pas été prévenus non plus (ou juste un peu avant) aussi, on dirait, donc cela semble ne pas être lié à une quelconque philosophie vis-à-vis des embargos. Dragonfly semble avoir patché déjà, mais pas dans
-stable, uniquement dans la branche de développement, mais la vitesse de réaction est impressionante.Ceci dit, au moins maintenant on est conscients de la faille, ce qui permet de savoir quels genre de services sont particulièrement risqués et à désactiver si possible (grosso modo, n'importe quoi qui permette d'exécuter à un tiers du code en tant qu'utilisateur local du système ou dans une vm).
Il est intéressant, mais pas surprenant (divulguer plus largement est un risque), de voir que pour des failles moins critiques, avec des embargos plus courts, la plupart des BSDs, ainsi que beaucoup de distros sont mis au courant, alors que pour une faille de ce type avec 6 mois d'embargo uniquement Linux, Mac OS et Windows reçoient une alerte bien à l'avance.
[^] # Re: OpenBSD
Posté par Guillaume Knispel . Évalué à 4.
Et encore, Linux (au sens les mainteneurs officiels principaux) n'a ne semble-t-il reçu qu'une demi info :/
# Firefox aussi à jour
Posté par Olivier Esver (site web personnel) . Évalué à 4.
La version 57.0.4 corrige(ou du moins essaye) la faille Spectre
Mis à jour sur Android et PCs, pas de différence sur PC. Sous android j'ai pas l'impression que ce soit plus lent mais des personnes se plaignent de la lenteur sur le play store…
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Firefox aussi à jour
Posté par Anonyme . Évalué à 2.
et le correctif pour l'ESR c'est fin du mois
Les raisons peuvent être diverses entre les appareils avec des SOC ARM in-order déjà limites en charge, les serveurs à l'autre bout qui doivent parfois être impacté en terme de latence et les biais de l'effet psychologique.
# Linux 4.14.12
Posté par Arthur Accroc . Évalué à 8.
Il y a quelques jours (2 janvier) sortait le noyau 4.14.11, introduisant KPTI comme protection contre Meltdown.
Le noyau 4.14.12 est sorti hier (5 janvier), incluant notamment :
– le patch désactivant KPTI sur les AMD, célèbre pour sa description qui a vendu la mèche concernant Meltdown (alors que les patchs précédents avaient volontairement des descriptions absconses) ;
– quelques correctifs concernant KPTI.
Extrait du changelog concernant le patch pour les AMD :
Extrait du changelog concernant l’un des patchs correctifs (contre une erreur qui d’après la description peut dans le pire des cas causer un crash du noyau) :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Bug (ou fonctionnalité ?)
Posté par freezed . Évalué à 5.
Il me semblait que depuis le bug de division des Intel Pentium Pro, les fondeurs avait fait beaucoup d'efforts pour vérifier voire "prouver" le bon fonctionnement de leurs CPUs.
Du coup cela semble assez curieux de constater que plusieurs fondeurs travaillant chacun sur une architecture différente, avec des équipes de développement différentes, … , avec une machine à café différente aient réussi à concevoir, réaliser, tester, vérifier et "prouver" le même bug (ou fonctionnalité ?).
N'étant ni un grand spécialiste du sujet, ni un adepte des théories conspirationnistes, je serai très intéressé par l'avis des connaisseurs.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Une théorie plus simple : si tu demandes à un collégien qu'elles sont les racines de x2 = -1, il dira qu'il n'y en a pas. Si tu demandes à un élève en fin de lycée, il dira une racine double i. Le premier ne peut même pas imaginer l'existence de la solution. Il existe des cas où l'on découvre une nouvelle catégorie de problèmes/bugs, et forcément on n'avait pas mis en place des solutions aux problèmes/bugs que l'on ne connaissait pas encore. Or on découvre de temps en temps de nouvelles catégories de bugs (et on ne prouve que ce que l'on a spécifié).
Après on oublie aussi certaines catégories qui resurgissent plus tard (par exemple on sort un nouveau langage, sans IDE, sans bon compilateur, sans outils de vérification de code, etc. et hop on retrouve des vieux bugs). On a aussi des bugs connus mais que l'on pensait inexploitables en pratique et en fait si.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par gouttegd (site web personnel) . Évalué à 6.
Oui. À ma connaissance, les premières attaques par canaux cachés visant les caches du processeur datent de cette décennie (p.ex. Gullasch et al. 2011, Hund et al. 2013, Irazoqui et al. 2015, etc.).
Si c’est réellement le cas (je ne prétends avoir fait le tour de la littérature sur la question, peut-être qu’il y a des travaux plus anciens), je pense qu’on peut difficilement reprocher aux fondeurs de n’avoir pas su empêcher, dans leurs designs datant pour certains du milieu des années 90, des attaques qui ne seront imaginées que dix ou quinze ans plus tard.
Intel est la risée d’Internet pour avoir dit ces derniers jours, en substance, « nous n’avons pas merdé, nos processeurs fonctionnent exactement comme prévu », mais ils n’ont pas forcément tort sur ce point.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Pinaraf . Évalué à 7.
À partir du moment où les accès mémoires sont faits avec un contrôle a posteriori, il y a un risque non négligeable. Et a priori AMD n'a pas pris ce risque. Pourquoi serait-il normal de prendre ce risque, et surtout d'affirmer que non non c'est normal qu'on fasse ça ?
Spectre est difficilement reprochable, par contre Meltdown c'est quand même provoqué par un choix de conception qui parait assez «osé».
[^] # Re: Bug (ou fonctionnalité ?)
Posté par gouttegd (site web personnel) . Évalué à 4.
Les auteurs de Meltdown ne savent pas très bien pourquoi leur attaque n’a pas réussi sur les processeurs AMD et ARM, mais les tests qu’ils ont réussi à faire montrent qu’avec ces processeurs aussi, les contrôles sont fait a posteriori :
Pour les auteurs, il semble établi que, sur le papier au moins, Meltdown devrait fonctionner aussi sur des processeurs non-Intel, il n’y a pas de différence conception suffisamment grande entre les fondeurs. Ce n’est peut-être qu’une question de temps avant de voir débarquer une version de Meltdown qui fonctionne sur d’autres processeurs.
Parce qu’on n’imaginait pas à l’époque le genre d’attaques par canaux cachés que l’on imagine à présent.
Peut-être que les ingénieurs de l’époque étaient nuls, peut-être qu’ils étaient tous achetés par la NSA. Ou peut-être qu’ils n’avaient pas le bénéfice des quinze dernières années de recherche.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Pinaraf . Évalué à 8.
J'indiquais qu'AMD semble ne pas avoir pris ce risque en me basant sur les dires du développeur AMD sur la LKML : https://marc.info/?l=linux-kernel&m=151435344819700
Donc effectivement il y a un truc suspect vu que le code a été exécuté… Peut-être les instructions sont exécutées mais sans lecture des données ? Ce qui serait un peu idiot, certes, mais compatible avec le fait que l'accès mémoire ait été bloqué, et que l'attaque n'ait pas réussi.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par spart . Évalué à 4.
Oui, je pense que tu as raison, c'est écrit noir sur blanc :
"La micro-architecture AMD n'autorise pas les références mémoires, y compris les références spéculatives, à accéder à des données d'un niveau de privilège supérieur depuis un mode d'exécution moins privilégié, si cet accès devait provoquer une erreur de page."
Franchement, c'est parfaitement clair. Je le traduis juste parce qu'apparemment, ça n'a pas été bien compris par tout le monde.
De ce fait, peu importe que des instructions continuent ou non d'être exécutées spéculativement : il n'y a pas de fuite de données. CQFD.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par JN . Évalué à 3.
Enfin, les recherches sur les canaux cachés ne sont pas neuves non plus.
Mon sentiment sur cet épisode regrettable :
Sans avoir idée des moyens de les mettre à profit, une énumération à froid de tout ce qui n'est pas effacé lors des changements de contexte suffirait à savoir ce qui est à risque et ce qu'il faut protéger en particulier. Pour les canaux cachés (enfin pas tant que ça, quand on parle de cache), tout ce qui n'est pas explicitement permis devrait être interdit. Facile à dire, je le concède, mais le principe est simple.
Dans l'industrie manufacturière, on a un mantra : "sécurité d'abord". Pour l'informatique, c'est "sûreté d'abord" mais on a franchement l'impression que les fondeurs n'ont pas cherché à suivre les nouveautés en matière de sécurité. Et on ne parle pas de petite startup avec 3 pelés et pas de moyens. La réflexion de Torvalds me paraît amplement méritée.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Renault (site web personnel) . Évalué à 10.
Ne pas oublier que la question de la sécurité est devenue centrale depuis très peu de temps, en fait depuis que n'importe quelle machine ou application (ou presque) ont accès à Internet. Avant cela la sécurité était une liste de bonnes pratiques mais on n'allait pas au fond du sujet, faute de compétences et d'intérêts. Aujourd'hui potentiellement toute faille fait l'objet d'une mise en garde sérieuse, c'était beaucoup moins vrai il y a 5 ou 10 ans.
Donc que des concepteurs d'une machine bas niveau, dont une bonne partie de sa conception date d'il y a longtemps (Intel ne change pas tout en profondeur à chaque génération) ait manqué ce genre de choses ne me paraît pas aberrant. Un processeur reste une puce très complexe, et il est probable que les équipes de sécurité de la boîte n'ait pas tout épluché en profondeur voire ne parvienne pas à le faire entièrement car comme c'est complexe, c'est difficile de tout déceler.
Par contre ce qui est certains, c'est que la prochaine génération devra corriger ce genre de bévues. Et peut être même corriger des soucis similaires mais jusque là inconnus. Dans le cas contraire ce serait très embêtant et ils pourraient difficilement utiliser cette ligne de défense.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par gipoisson . Évalué à 9.
Je n'ai pas d'expertise non plus sur la question, mais divers experts disent que la problématique a été explorée bien avant les années 2010, en témoignent ces quelques discussions sur la toile :
Colin Percival en réponse à Daniel Gruss, un des auteurs du papier « KAISER »
Alex Ionescu :
À mon avis, il est trop tôt pour établir si les fondeurs ont agi de bonne foi ou non. Peut-être qu'avec beaucoup plus de recul, une historique plus fournie sortira pour éclairer ce point.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Ce commentaire sur hacker news parle également de travaux dans les années 90, sur VAX : https://news.ycombinator.com/item?id=16092183. S'en suit une discussion pour savoir si ces travaux auraient dû ou non mettre la puce à l'oreille d'Intel.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 7.
Voir aussi l’avertissement de deraadt@ en 2007 : Intel Core 2.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par lasher . Évalué à 4.
C'est littéralement ce que nous nous disions dans mon labo y'a ~10 ans lorsqu'on a vu des papiers montrant qu'on pouvait récupérer les clefs privés de GnuPG en passant par des side-channel attacks sur le cache : « dans la vraie vie y'a trop de bruit sur un serveur à cause de tous les processus qui tournent pour que ça puisse marcher ». Et bim, 10 ans plus tard, Spectre et Meltdown arrivent.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par lasher . Évalué à 3. Dernière modification le 17 janvier 2018 à 12:06.
En l'occurrence, la notion d'analyse du prédicteur de branchement et d'utilisations d'attaques par timing pour récupérer des infos du cache de données avait déjà été abordée dès 2005-2007. Voir ici par exemple.
EDIT: pas vu une autre réponse plus complète que la mienne…
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Yth (Mastodon) . Évalué à 7.
Nope, deux racines, i et -i !
Yth :)
[^] # Re: Bug (ou fonctionnalité ?)
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Ah la catégorie de bugs due à l'inattention… Bien vu.
# Comment le cache peut être lu ?
Posté par Wawet76 (site web personnel) . Évalué à 4.
D'après ce que j'ai compris, la faille fonctionne en 2 temps :
- Un problème avec l'exécution prédictive fait qu'une donnée qui ne devrait pas pouvoir être lue se retrouve dans un cache du processeur.
- Le contenu de ce cache est "deviné" en regardant combien de temps le processeur mets à faire un autre truc.
J'ai bien compris la première partie, mais je ne pige pas la deuxième. Les articles que j'ai lus sont soit incompréhensibles (pour moi), soit trop simplifiés pour comprendre le mécanisme.
[^] # Re: Comment le cache peut être lu ?
Posté par Pinaraf . Évalué à 6.
Alors, en fait, l'astuce c'est d'avoir un petit bout 'partagé' dans le cache.
L'attaque repose, très grosso modo, sur le pseudo-code suivant :
L'attaque nécessite de faire croire au processeur qu'il va exécuter le code dans le if. Il fera alors les accès mémoire de ce code…
Et si maintenant on fait une boucle sur mon_tableau, alors il y aura normalement une entrée qui sera en mémoire cache, et donc beaucoup plus rapide d'accès. CQFD…
Est-ce plus clair ?
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 8.
Non ce n'est pas tout à fait cela. Aux premiers abords, ta version semble plus maline que ce qu'on lit ailleurs (où ils lisent bit par bit) car tu lis un octet d'un seul coup! Mais je pense que la raison pour laquelle ce n'est pas fait est que le processeur ne met pas seulement en cache une adresse accédée, mais aussi ses voisins (pour des raisons d'efficacité; comme tu le prouves toi-même, quand on accède à une valeur, on va probablement accéder à son voisin bientôt). Par conséquent:
Ben là déjà, tu as corrompu les données. En lisant un index, tu mets en cache ses voisins et donc le compte du timing n'a plus de valeur pour les données voisines.
En fait c'est là où est ton erreur. Faire une opération sur la valeur n'a absolument aucune sorte d'intérêt ici. Cette valeur va disparaîtra de toutes façons. En fait l'opération est faite sur l'index, déjà pour placer ton cache à des index connus (quelle que soit l'adresse lue), ensuite vraisemblablement pour placer les deux valeurs à comparer à des index bien séparés pour ne pas corrompre le cache. Je n'ai effectivement pas lu d'explication claire sur ce point précis, mais cela me semble la raison évidente pour laquelle toutes les explications font cela (autrement, pourquoi se faire chier et pas simplement faire un tableau avec 2 valeurs? Ben parce qu'elles seraient trop proche et en lire une mettrait vraisemblablement la seconde en cache immédiatement donc aucun calcul de timing possible!). Donc on lit en général des trucs du genre:
Note qu'on s'en fout de la valeur x, qui peut d'ailleurs être locale (c'est juste histoire de); de même il n'est pas besoin d'écrire dans
mon_tableau. On s'en fout, ça sera annulé. On veut juste lire son contenu, ce qui le mettra en cache (et ses voisins!). Et là, en fonction que le premier bit sera 0, ou 1, on mettra en cache l'index 0 ou 256! Et ce sont des index suffisamment éloignés pour ne pas craindre que le processeur ne mettra l'un en cache car il a lu l'autre.Donc non, ce n'est pas n'importe quelle opération qu'il faut faire, mais une opération faite pour éloigner les 2 index possibles et avoir des index connus (on ne veut surtout pas avoir à "chercher" car ça corromprait le cache et rendrait le calcul de timing inadéquat).
Bien sûr, pour lire le second bit, il faut tout refaire, et la fois suivante, construire l'index ainsi:
Ce qui encore une fois mettra en cache soit l'index 0 (et voisins) soit l'index 256 (et voisins).
Et ainsi de suite… En juste 8 boucles de ce code (en paramétrant le décalage), on a lu un octet complet.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Pinaraf . Évalué à 3.
On peut plus faire de grosso modo tranquille de nos jours… :)
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Ben c'est surtout que je pense que la partie vraiment significative de l'attaque est le fait de transformer une valeur en index, ce qui se perdait dans ton code. :-)
Et surtout "écrire" dans le cache n'a aucune espèce d'importance. Donc pour une explication simple du problème, je pense qu'il est important que tout bout de code exemple ne fasse surtout pas d'écriture (car les gens vont s'y focaliser et croire que ce qu'ils sont en train de louper est dans cette opération d'écriture). La ruse est vraiment la lecture d'une adresse construite. On s'en fout du contenu lu, on veut juste savoir si on a lu à cet index.
Et l'erreur des constructeurs de CPU, c'est vraiment qu'ils se sont aussi focalisés sur la valeur justement, sans prendre en compte que les index aussi avaient leur importance, que c'étaient aussi des nombres et donc qu'on pouvaient finalement les utiliser pour faire passer des données en douce. :-)
C'est là toute la ruse de cette attaque et si on veut l'expliquer aux gens, c'est ce point ("transformer une valeur en index") qu'il faut appuyer et qui devrait pouvoir faire un déclic de compréhension à mon avis.
Enfin voilà. Mon but n'était pas vraiment de dire que ce que tu disais était entièrement faux. Je voulais surtout appuyer sur ce point de détail qui pour moi est le plus significatif (aussi bien pour la vulgarisation que pour l'explication détaillée et technique du problème) alors que personne ne semble vraiment l'appuyer dans toutes les explications que j'ai lues jusque là.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par foobarbazz . Évalué à 1.
Non, je ne suis pas d'accord, c'est le fait de faire un calcul dépendant de cette valeur, de sorte que ce calcul laisse une trace dans le cache. Dans ça forme la plus abstraite ça donne :
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Oui tout à fait, et justement, ça laisse une trace sous la forme… d'un index!
C'est donc exactement mon propos. Tu t'intéresses pas du tout à ce qui est dans le cache, tu t'intéresse juste à sa voir si cet index (
adresse_1est un index) est dans le cache. L'info intéressante ici est essentiellement cet index. C'est exactement ce que fait ton code.Tu aurais fait ce même calcul en utilisant les mêmes données (dont la valeur interdite) et l'aurait laissé dans le cache sous la forme d'une valeur, ça n'aurait servi strictement à rien (puisque le changement de valeur aurait été défait).
Donc si, on est d'accord. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par foobarbazz . Évalué à 1.
Oui, je vois. Je pensais souligner le fait qu'il n'y a absolument pas besoin d'utiliser la valeur que l'on veut lire comme un index.
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3.
En effet, tu soulignes un point intéressant pour encore améliorer l'abstraction. En fait, on ne calcule pas l'index en fonction de la valeur interdite du tout (on connaît ces index/adresses dès le début).
Les trucs barbares de type…
… ne sont pas des calculs (symboliquement parlant). Ce sont juste des tests de conditions sur la valeur de bits de c (la valeur interdite), qui sont simplement faits sous la forme de calculs (parce que dans un ordi, tout est calcul en fait) et en code encore plus simplifié (mais plus long), ça revient donc à:
Je remplace aussi le
apar_, pour indiquer qu'on se fiche du résultat (syntaxe qu'on trouve dans certains langage), pour vraiment amplifier le fait que cette assignation de valeur n'est vraiment pas le point central (et n'a même aucune importance en fait).Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7.
En version simplifié!
En fait, l'erreur, c'est de s'accrocher à croire que le fait que la valeur interdite puisse se retrouver dans le cache a une quelconque importance. Ça n'en a aucune, d'autant plus que dès que la prédiction se révèlera fausse, toute donnée changée (cache compris) est remise à l'état initial.
Par contre, on a eu accès à la vraie valeur (lors de l'exécution prédictive), et à partir de cette valeur, on a pu construire un index pour une donnée utilisateur et cet index est légal et connu! C'est ça la ruse! On a transformée une valeur inconnue en un index connu! Et bien sûr, on a effectué une lecture à cet index qui sera notre seule donnée légale en cache.
Alors si cet index est connu, quel intérêt? En fait je me corrige: on a transformé une valeur inconnue en 2 index connus! C'est la raison pour laquelle cette attaque va lire les données bit par bit (car on obtient une réponse binaire).
Et on va simplement comparer la vitesse de lecture de ces 2 index. Note bien qu'on s'en fout toujours autant de la valeur réelle de ces 2 index. On veut juste savoir lequel est le plus rapide à lire (c'est à dire lequel est en cache), ce qui nous permet de déterminer si le bit est à 0 ou 1.
Puis on passe au bit suivant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comment le cache peut être lu ?
Posté par freezed . Évalué à 2.
En butinant je suis tombé sur cette présentation "grand public" très bien faîte et tout en métaphore du bug Meltdown. Peut-être cela peur vous intéresser :
http://www-verimag.imag.fr/wordpress/maraninx/une-petite-experience-de-vulgarisation-sur-le-bug-meltdown/
[^] # Re: Comment le cache peut être lu ?
Posté par Wawet76 (site web personnel) . Évalué à 2.
Effectivement, je ne comprenais pas comment on pouvait lire le contenu d'un cache en observant les temps d'accès.
J'ai compris avec ton explication que ce n'était pas ça qui était fait. Merci.
# Nouveaux microcodes intel
Posté par Olivier Esver (site web personnel) . Évalué à 6.
Je viens de voir qu'Intel a mis à jour sur son site les microcodes.
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Nouveaux microcodes intel
Posté par chrisemail . Évalué à 2.
Si j'ai bien tout compris, le microcode du cpu peut se mettre à jour via le BIOS/UEFI et/ou avec l'OS.
Donc pour se protéger de Spectre Variant 2, il faut maj le microcode (en plus du patch kernel) :
- soit part la maj du bios/uefi du constructeur
et/ou
- soit par le package fourni par intel ou par un package fourni par notre distribution préférée (intel-microcode pour debian, microcode_ctl pour rhel, etc).
[^] # Re: Nouveaux microcodes intel
Posté par Anonyme . Évalué à 2.
Si ce n’est pas déjà fait :
apt-get install intel-microcode.[^] # Re: Nouveaux microcodes intel
Posté par Olivier Esver (site web personnel) . Évalué à 2.
Il me semble qu'il faut ensuite modifier le fichier /etc/default/intel-microcode pour une prise en compte à la prochaine install du noyau.
J'avais aussi installé le paquet iucode-tool.
Hélas je n'ai pas pu tester car les mises à jour ne concernent pas les CPU que j'ai (ou leur bios est déjà à jour, pour mon probook HP a fait une mise à jour début janvier)
S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
[^] # Re: Nouveaux microcodes intel
Posté par Anonyme . Évalué à 3.
C’est bien activé par défaut :
# Cela devient gonflant ...
Posté par ledufakademy . Évalué à -10.
Ce business de la peur gonfle vraiment, on va bientôt plus que se consacrer sur la sécurité : vous êtes tous des mougeons (c'est volontairement TRES provocateur).
La plupart des soit-disants experts en sécurité sont des charlots, des vendeurs de rêve comme dans "Total Recall" et je pèse mes mots car je sais d’où je viens, je respecte le hacker …
Je vais donc tâcher de répondre calmement et très précisément à ce genre de news lourdingue et conditionnantes :
Note : je connais dès tech.* qui ont des clefs de 10Gbits … ils se reconnaitront.
« Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne mérite ni l’une ni l’autre, et finit par perdre les deux. » : servez-vous c'est libre, B.FRANKLIN
« LA vraie sécurité c'est faire en sorte que son ennemi devienne un ami» … tout est dit ici.
Bon week
[^] # Re: Cela devient gonflant ...
Posté par ledufakademy . Évalué à -10.
… et je rajouterai que nous sommes à quelques décennies de tout basculer nos données, notre santé, nos familles … enfin notre âmes dans ces foutus DataCenter : je pense que nous ne prenons pas forcément la meilleur route, vraiment pas.
Pierre Rhabi parle leur de la décroissance … stp.
# Bonne année Intel
Posté par Nicolas Chevallier (site web personnel) . Évalué à 1.
Le grand public commence à comprendre que les boites mettent très peu d'argent/moyens dans la sécurité, que ce soit hard ou soft. Bien muavais début d'année pour Intel…
# Cloud et privateur
Posté par galex-713 . Évalué à -4.
Ah merde, ça voudrait donc dire qu’on pourrait plus faire de cloud ou de logiciel privateur en toute pérennité ? ah bah merde alors…
Bon bah du coup moi ça me concerne pas… :-°
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.