COMPTOIR
  
register

Composé par ————— —— 15952 vues

Spoiler : encore une faille pour les CPU Intel...

Rebelote, après le couple Meltdown/Spectre, le combo Spectre-NG, LazyFP, L1 Terminal Fault ou encore Portsmash, une énième nouvelle vulnérabilité a été découverte chez les processeurs Intel ; par contre ni AMD ni ARM (les chercheurs auraient passé les deux en revue) ne sont a priori concernés par cette petite trouvaille. Baptisée Spoiler, la découverte de cette faille est à attribuer à l'Institut Polytechnique de Worcester en partenariat avec l'Université de Lübeck, et elle implique tous les processeurs Intel mis sur le marché depuis les débuts de l'architecture Core - à l'image des vulnérabilités Meltdown et Spectre premiers du nom - autant dire que ça en fait toujours un sacré paquet ! Rien de plus normal, puisque l'origine de la faille du jour est la même que pour les deux susmentionnées, c'est-à-dire la vilaine exécution spéculative, ou plutôt la manière dont celle-ci a été implémentée. Selon les chercheurs, la vulnérabilité fonctionne indépendamment de l'OS, de la machine virtuelle ou d'une sandbox... et donc exploitable via un simple code JavaScript lancé depuis un site web malveillant.

 

intel meme cries in core

 

En fait, le problème vient ici du fait que l'exécution spéculative effectuée lors d'une écriture mémoire suivant de très près une autre écriture, où le processeur va tenter de transmettre directement les données à l'unité de lecture, évitant ainsi le coût d'un accès mémoire. Or, il est possible détourner le mécanisme pour obtenir des informations sur la localisation physique des données dans la RAM ou le cache. Vous ne le sentez peut-être pas venir, mais cela est très mauvais, car la connaissance de ces emplacements physiques permet d'accélérer grandement d'autres attaques, menant à la lecture de zones mémoires protégées voire l'élévation de privilèges jusqu'aux droits administrateurs. Hélas, comme c'est déjà le cas pour plusieurs des vulnérabilités de ce type (d'autres ont par exemple été "corrigés" avec l'introduction des Core 9000), les chercheurs affirment que Spoiler ne pourra pas être patché via une simple solution logicielle, signifiant que le salut ne viendra qu'en corrigeant l'architecture même des processeurs concernés. Bref, il ne fait aucun doute que les fabricants de microprocesseurs et leurs futures nouveautés ont du pain sur la planche pour revoir les choses en profondeur - trop tard pour Sunny Cove et Zen 2 ? - c'est pourtant un peu de vous qu'on parle ! Rira bien qui rira le dernier, non ?

 

Le White Paper qui explique tout.

 

amd meme laughs in ryzen

Un poil avant ?

Le diable pourrait chialer chez AMD aussi avec le nouveau pilote

Un peu plus tard ...

4 ans plus tard, les derniers CPU de la 6e génération Skylake officiellement mis à la retraite !

Les 20 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Un ragoteur 'technophile' en Auvergne-Rhône-Alpes, le Samedi 09 Mars 2019 à 02h35  
par Un ragoteur qui draille en Île-de-France le Vendredi 08 Mars 2019 à 23h44
A l'évidence, ça devrait être le cas. De toute manière ce n'est pas une faille mais comme le dirait M$, une feature, qui facilite grandement les failles...
C'est pas si simple, pour le coup ce n'est vraiment pas une faille, juste un side channel qui fait fuiter l'adressage physique. C'est une information que le mode user on n'a pas mais pas parce-que c'est dangereux, juste parce-que ça sert à rien normalement.

Il ne faut pas confondre les vraies problèmes de conception comme Meltdown, spectre, L1TF, .. avec ce timing side channel dont l'existence est évidente et sans danger. De toute façon, si ce side channel n'existait pas on en aurait trouvé d'autres.

Il n'est pas possible de construire une archi qui va économiser un maximum de cycles en exploitant des propriétés des états architecturaux sans que l'on puisse déduire des informations sur ces états architecturaux via des mesures de perf (puisque justement économiser des cycles fait gagner en perf !).
par Un ragoteur qui draille en Île-de-France le Vendredi 08 Mars 2019 à 23h41
Oui, alors attention, il est possible de faire fonctionner un CPU de façon différente, en protégeant les adresses, mais en gardant l'optimisation, le dessin sera nécessairement beaucoup plus lourd, donc probablement lent.
Non si on veut bloquer les timing side channel permettant de déduire l'adressage physique il faut que tous les accès mémoires aient la même latence. Dans ce cas AUCUNE optimisation n'est possible (ou utile) et le résultat serait OBLIGATOIREMENT lent. Mais protéger l'adressage physique n'est pas utile si le reste de l'architecture bon
par Un ragoteur qui draille en Île-de-France, le Vendredi 08 Mars 2019 à 23h44  
par Ideal le Vendredi 08 Mars 2019 à 10h49
Perso
...Mais bien sûr personne n'est dupe, AMD n'est surement pas à l'abri d'une quelconque faille ou d'une vulnérabilité semblable à l'archi Intel, c'est un point que j'ai essayé d'exprimer...
A l'évidence, ça devrait être le cas. De toute manière ce n'est pas une faille mais comme le dirait M$, une feature, qui facilite grandement les failles...
par Un ragoteur qui draille en Île-de-France, le Vendredi 08 Mars 2019 à 23h41  
par Zoroastre le Vendredi 08 Mars 2019 à 19h40
Merci pour tes précisions Je me doute qu'une marche arrière est quasi impossible surtout a l'heure ou on code de moins en moins proche du metal
Oui, alors attention, il est possible de faire fonctionner un CPU de façon différente, en protégeant les adresses, mais en gardant l'optimisation, le dessin sera nécessairement beaucoup plus lourd, donc probablement lent.
par Un ragoteur qui draille de Bretagne, le Vendredi 08 Mars 2019 à 21h51  
profanation de qualitay
par Zoroastre, le Vendredi 08 Mars 2019 à 19h40  
par Un ragoteur 'technophile' en Auvergne-Rhône-Alpes le Vendredi 08 Mars 2019 à 13h56
Si on retire le Out Of Order et l'exécution spéculative cela va forcement entraîner une grosse baisse de perf, même en codant bien, même avec des compilo super bien fait.

Je t'invites à te renseigner sur la différence entre le static scheduling (organiser les instructions à compile time) et dynamic scheduling (organiser les instructions au runtime sur le CPU).

Pour une console avec un hardware fixé, et un seul système qui tourne le static scheduling peut-etre adapté mais il est tout de même complexe. Pour un PC general purpose comme tu as chez toi le hardware peut changer, l'environnement d'exécution aussi et cela a de l'importance pour le scheduling des instructions, or tout ceci ne peut pas être connue à compile time donc du static scheduling va forcement entraîner une baisse de perf dans ces conditions.
Par contre du static scaduling réduit drastiquement la consommation électrique.

C'est parce-que les clients voulaient toujours plus de perf que Intel est partie dans cette direction. Et je ne pense pas que les gens soient près a revenir en arrière niveau perf.

Tu peux aussi regarder l'itanium de intel (une archi VLIW) qui a justement essayé des choses dans ce sens.
Merci pour tes précisions Je me doute qu'une marche arrière est quasi impossible surtout a l'heure ou on code de moins en moins proche du metal
par Un ragoteur 'technophile' en Auvergne-Rhône-Alpes, le Vendredi 08 Mars 2019 à 13h56  
par Zoroastre le Jeudi 07 Mars 2019 à 22h19
Bon ben retour au bon vieux In order et que les devs se sortent les doigts pour coder proprement dessus
Les PS3 et Xbox 360 avaient du In order sur leurs cpus et on avait accomplit de véritables prouesses sur ces machines
Si on retire le Out Of Order et l'exécution spéculative cela va forcement entraîner une grosse baisse de perf, même en codant bien, même avec des compilo super bien fait.

Je t'invites à te renseigner sur la différence entre le static scheduling (organiser les instructions à compile time) et dynamic scheduling (organiser les instructions au runtime sur le CPU).

Pour une console avec un hardware fixé, et un seul système qui tourne le static scheduling peut-etre adapté mais il est tout de même complexe. Pour un PC general purpose comme tu as chez toi le hardware peut changer, l'environnement d'exécution aussi et cela a de l'importance pour le scheduling des instructions, or tout ceci ne peut pas être connue à compile time donc du static scheduling va forcement entraîner une baisse de perf dans ces conditions.
Par contre du static scaduling réduit drastiquement la consommation électrique.

C'est parce-que les clients voulaient toujours plus de perf que Intel est partie dans cette direction. Et je ne pense pas que les gens soient près a revenir en arrière niveau perf.

Tu peux aussi regarder l'itanium de intel (une archi VLIW) qui a justement essayé des choses dans ce sens.
par Ideal, le Vendredi 08 Mars 2019 à 10h49  
Perso j'ai pas lu "Le White Paper" car je pars de trop loin niveau technique + en anglais pour rien faciliter, mais je suis l'affaire des failles depuis le début en lisant les articles jusqu'au bout au minima. ( d'ailleurs j'ai bcp apprécier lire ton post très compréhensible )
Mais bien sûr personne n'est dupe, AMD n'est surement pas à l'abri d'une quelconque faille ou d'une vulnérabilité semblable à l'archi Intel c'est un point que j'ai essayé d'exprimer.

D'ailleurs comme tu le dis à la fin tout est une question de choix ... que ce soit en software ou hardware il faut toujours faire des choix de ce type et la sécurité de base est toujours privilégier tant qu'elle grappille pas trop de perf. Tous les acteurs du marché doivent "deal with it" ce qui est pas normal c'est que ces failles soient découvertes par des universités et non pas évitées en amont par les fabricants.. que ce soit AMD ou Intel ou autre.

Mais un jour, l'informatique aura atteint un espèce de plafond de verre niveau performance brute, la sécurité sera la principale préoccupation du marché (un peu comme ce qu'on peut percevoir dans les pubs d'automobiles) et là une erreur comme celle qu'Intel a vu être révélé sera encore bien + impactante que ce qu'on peut voir maintenant #madameirmaunpeu
par Un ragoteur 'technophile' en Auvergne-Rhône-Alpes le Vendredi 08 Mars 2019 à 08h59
Long et intéressant post
par Un ragoteur 'technophile' en Auvergne-Rhône-Alpes, le Vendredi 08 Mars 2019 à 08h59  
par Ideal le Jeudi 07 Mars 2019 à 20h38
Ce que l'on comprend du début de l'article à ce sujet " why not AMD? ".

Et ce que je comprend de la fin de l'article c'est que l'archi AMD a certainement ces propres failles, et si elles étaient découvertes maintenant bah il serait trop tard pour y remédier sur Zen2. D'où le "les fabricants [...] ont du pain sur la planche pour revoir les choses en profondeur"
En faite, si tu regardes le papier, ce side-channel à été construit en fonction de l'architecture de Intel. Tout le début de l'article consiste à expliquer des mécanismes de cette en particulier les stores forwarding qui est une optimisation qui est correctement implémenté. Puis ils en déduisent un timing side channel, et ils savaient qu'ils allaient en trouver c'est plus que normal dans une archi opti pour la vitesse. À la suite de ça ils expliquent comment utiliser ce side channel pour booster des attaques déjà connues. C'est un énorme travail tout ça.

Bref, tout a été construit sur ce qu'on connaît des archi Intel (car elle sont beaucoup étudiées, plus que celle de AMD). Ce qu'ils ont fait pour AMD c'est juste lancer les mêmes programmes sur AMD, parceque on sais jamais.. et ils disent qu'ils n'observent pas les mêmes comportements. Et c'est normal l'architecture est différente et ils n'ont pas étudier l'archi de AMD. On peut seulement en déduire que cela valide que l'architecture et différente, pas qu'il n'existe pas de timing side channel sur AMD (car il en existe à coup sûr).

Et la présence de timing side channel n'est pas spécialement un mal vu que le CPU n'est pas construit pour être protégé de cela, il est construit pour la perf et les 2 sont incompatibles il faut faire un choix.
par Zoroastre, le Jeudi 07 Mars 2019 à 22h19  
Bon ben retour au bon vieux In order et que les devs se sortent les doigts pour coder proprement dessus
Les PS3 et Xbox 360 avaient du In order sur leurs cpus et on avait accomplit de véritables prouesses sur ces machines
par Ideal, le Jeudi 07 Mars 2019 à 20h38  
"par contre ni AMD ni ARM (les chercheurs auraient passé les deux en revue) ne sont a priori concernés par cette petite trouvaille. Baptisée Spoiler"
Ce que l'on comprend du début de l'article à ce sujet " why not AMD? ".

Et ce que je comprend de la fin de l'article c'est que l'archi AMD a certainement ces propres failles, et si elles étaient découvertes maintenant bah il serait trop tard pour y remédier sur Zen2. D'où le "les fabricants [...] ont du pain sur la planche pour revoir les choses en profondeur"

Après tout les failles Spectre/Meltdown et maintenant Spoiler sont découvertes avec 10 ans de retard maintenant. AMD peut tout à fait avoir sa propre story "Meldown ou Spoiler" qui touchera son archi et non celle Intel ( déjà violée ), Spectre touche autant les uns les autres il me semble je la met à part.
par Jemporte le Jeudi 07 Mars 2019 à 18h46
Ce n'est pas ce qu'on comprend dans l'article mais bien que Zen 2 serait touché (ce qui n'est pas d'emblée le cas mais sait-on jamais). Par ailleurs AMD semble avoir fait des efforts au niveau de l'optimisation de ses Zen2 pour les branchements spéculatifs ce qui n'est pas de bonne augure contre ce genre de faille. Il faudra vraiment voir et vérifier que Zen 2 "n'innove pas" dans le mauvais sens à ce niveau.
par Nicolas D., le Jeudi 07 Mars 2019 à 18h53  
par Un ragoteur qui a lu en Auvergne-Rhône-Alpes le Jeudi 07 Mars 2019 à 18h17
[...]
J'ai donc vraiment du mal avec le fait d'appeler ce comportement une "faille" (comme le fait l'article) puisque c'est un comportement attendu et que seul il est totalement passif. Le mot "side channel" ou "canal auxiliaire" est bien plus adapté car neutre (cela n'est pas une attaque c'est juste une extraction d'informations mais qui n'ont pas trop d'importance seules).
Je comprends mais parler de "side channel" est très (trop) technique pour certains, on veut rester généralistes. Je suis d'accord avec les faits que tu expose, cependant on va partir en débat philosophique sur des jugements de valeur qui ont moyennement leur place ici. Dans l'état actuel, blâmer un unique maillon de la chaîne (qu'il soit le canal auxilaire, effectivement un comportement plus ou moins attendu, ou ce que tu appelles "faille" comme Rowhammer) c'est lié à ta compréhension fine de la situation et ton jugement sur le fonctionnement interne "normal" du CPU.
Ici, nous déplorons l'ensemble menant à une vulnérabilité critique, menée par la découverte du maillon manquant : le canal auxililiaire (qui n'est lui pas patchable...). Le corps de l'article est normalement plus éclairant pour qui veut mieux saisir la situation (et pas juste retenir qu'il y a une faille critique, concept fumeux pour désigner RowHammer + canal aux), et la source est clairement mise en évidence pour les plus technophiles comme toi . Si pour toi il y a vraiment arnaque de notre part, n'hésite pas à envoyer une alerte, ça sera traité plus rapidement .
par Jemporte, le Jeudi 07 Mars 2019 à 18h46  
par Ideal le Jeudi 07 Mars 2019 à 09h43
Il est "trop tard" car ces architectures sont déjà bouclées et fignolées depuis un très long moment niveau IP et aussi depuis un certain temps niveau chaine de production.

MAIS en même temps AMD n'a pas été dans la même voie qu'Intel et donc n'est pas impacté ce qui est surement le cas aussi pour Zen2 sans qu'on en soit sûr pour le moment.

Cette faille spoiler a été révélé à Intel en décembre, AMD Zen2 sera surement pas atteint par Spoiler tout comme Zen et Zen+, voila ce que le rédacteur voulait dire
Ce n'est pas ce qu'on comprend dans l'article mais bien que Zen 2 serait touché (ce qui n'est pas d'emblée le cas mais sait-on jamais). Par ailleurs AMD semble avoir fait des efforts au niveau de l'optimisation de ses Zen2 pour les branchements spéculatifs ce qui n'est pas de bonne augure contre ce genre de faille. Il faudra vraiment voir et vérifier que Zen 2 "n'innove pas" dans le mauvais sens à ce niveau.