Faille Intel

L’auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut !

Ça semble sentir le roussi chez Intel. N’étant pas familier du bas niveau, je me demande quels usages seront touchés par la correction de cette faille ? On dit qu’on peut perdre jusqu’à 30% des capacités du processeur. Quelles puces ? Bref, si des personnes veulent bien vulgariser, je dirais pas non ^^

écolo-utopiste altermondialiste radicalisé sur Internet | La tero estas nur unu lando | Géographe de service | Cliquez 👍 pour dire merci

+0 -0

Cette réponse a aidé l’auteur du sujet

D’après des gens plus calés que moi, ça touche les programmes qui font beaucoup d’appels systèmes. Pour le particulier, ça devrait être relativement indolore ; pour les professionnels, en particlulier dans le cas des bases de données, ça fera plus mal.

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+0 -0

Le vrai problème se situe-t-il niveau performances ou sécurité au final ? Tout ça m’a l’air d’être soit très confus par manque de communication de la part d’Intel, soit du bruit pour pas grand-chose…

lthms, si jamais tu passes par là…

🦊 - ge0.github.io

+1 -0

Quelles puces ?

qwerty

Actuellement les patchs sont déployés sur tous les processeurs x86, sans distinguo entre AMD et Intel. Donc concerné ou non, chaque processeur sera "ralenti" selon l’usage qui en est fait.

JuDePom

J’ai pu lire le contraire, que ce serait désactivé par défaut.

Eskimon

Le code du Patch linux kernel ne semble pas le désactivé par défaut (sauf si le kernel est booté avec l’option "nopti", et je n’ai actuellement ni un linux ni un processeur AMD pour voir ce qu’il met par défaut)

1
2
/* Assume for now that ALL x86 CPUs are insecure */
 +  setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+0 -0

Une piste : http://people.oregonstate.edu/~jangye/assets/papers/2016/jang:drk-bh.pdf qui parle d’attaque par canaux auxiliaires.

Si j’ai bien compris, c’est le fait de prévenir d’une faille matérielle par des moyens logiciels qui cause des problèmes de performance assez indésirables.

🦊 - ge0.github.io

+0 -0
Auteur du sujet

En somme, vu que la faille est matérielle, faudra changer le matos ?

écolo-utopiste altermondialiste radicalisé sur Internet | La tero estas nur unu lando | Géographe de service | Cliquez 👍 pour dire merci

+0 -0

Les malchanceux qui auront 30% de chutes de perfs vont avoir mal …

Je sais pas pourquoi, mais quand je lis:

En gros, beaucoup d’IOs, (très) beaucoup de réseau sur la loopback (et pas en ethernet/wifi où la latence va masquer la perte)…

j’ai peur pour les Sandy Bridges en infiniband du boulot…

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

Quelles puces ?

qwerty

Actuellement les patchs sont déployés sur tous les processeurs x86, sans distinguo entre AMD et Intel. Donc concerné ou non, chaque processeur sera "ralenti" selon l’usage qui en est fait.

JuDePom

J’ai pu lire le contraire, que ce serait désactivé par défaut.

Eskimon

Le code du Patch linux kernel ne semble pas le désactivé par défaut (sauf si le kernel est booté avec l’option "nopti", et je n’ai actuellement ni un linux ni un processeur AMD pour voir ce qu’il met par défaut)

1
2
/* Assume for now that ALL x86 CPUs are insecure */
 +    setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
JuDePom

AMD dit ne pas être touché par la faille. :D Donc correctif :

1
2
3
4
-   /* Assume for now that ALL x86 CPUs are insecure */
-   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+   if (c->x86_vendor != X86_VENDOR_AMD)
+       setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+2 -0

@Gabbro Haha, pas mal, je suis passé à côté

Heureusement qu’il y a pas 500 fondeurs :P

EDIT: Ah, c’est pas encore dans la branche master, pour ça que je suis passé à côté !

Édité par JuDePom

+0 -0

Apparemment, le parc des Mac tournant sous la dernière version de macOS est déjà à jour pour contrer la faille.

Et visiblement il n’y a pas eu trop de répercussion sur les perfs … en tout cas rien de notable à grosse échelle puisque c’est un sujet qui n’a pas surgi ces dernières semaines.

(Ça fait plaisir de savoir qu’Apple a pas trainé des pieds pour le correctif.)

+0 -0

Pour info, les articles reliés aux failles trouvées récemment sont dispos :

J’ai pas mal potassé la seconde, elle semble plus intéressante techniquement. Elle est bien plus merdique parce que logiciellement, on ne peut pas y faire grand chose. Donc on ne peut pas corriger la faille en question sans revoir les architectures processeur en question.

De ce que j’ai compris, il y a plusieurs moyen de faire l’exploit, le papier en présente deux. Dans tous les cas c’est basé sur le fait d’exécuter spéculativement du code qui n’aurait pas dû être exécuté et l’utilisation d’un side-channel. Pour s’assurer qu’on va exécuter le mauvais code, on va commencer par entraîner le prédicteur de branche pour qu’il fasse le choix dont on a envie en tant qu’attaquant.

La première attaque fait ça pour une branche conditionnelle. On force le processeur à faire deux accès pourris, le premier qui va être celui qui contrôle la valeur de branche (et qui va entraîner la fausse prédiction) et le second qui fait l’accès "secret". Le temps qu’on s’aperçoive que le choix était pourri, le second accès va impacter le cache de telle manière qu’en l’observant ensuite, on puisse déduire quelle donnée était secrète.

La seconde fait ça pour un saut arbitraire. L’idée est d’entraîner le programme victime à sauter à un endroit qui va permettre de faire fuiter de l’information par l’utilisation d’un emplacement mémoire sur lequel l’attaquant à du contrôle. On donne cette valeur à une opération qui manipule des données secrètes et en sautant à l’opération qui manipule à la fois les données secrètes et la valeur de contrôle, on peut arriver à tirer les informations secrètes progressivement.

Cependant, je ne comprends pas encore tout du papier. En particulier, je ne comprends pas le degré de contrôle dont on a besoin l’attaquant, ni les contraintes qu’il doit respecter pour réussir l’attaque. Si quelqu’un a compris, une explication serait pas de refus.

En tout cas, il est intéressant de voir que finalement, cette seconde "faille" correspond en fait à un comportement voulu du processeur qui a été intelligemment détourné. Elle semble très difficile à exploiter mais le gain pour l’attaquant est énorme. Et dans le cas des clouds providers, on a presque l’impression que l’hyperviseur ne peut rien faire si la VM est configurée pour réaliser l’attaque, c’est assez impressionnant.

Finalement, à vouloir trop accélérer nos processeur sur single-thread, on a fini par se brûler les ailes.

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein [Tutoriel Frama-C WP]

+2 -0

De mon côté je potasse la première, et le problème vient à mon sens d’ici :

this hardware-based isolation through a permission bit is considered secure and recommended by the hardware vendors. Hence, modern operating systems always map the entire kernel into the virtual address space of every user process. As a consequence, all kernel addresses lead to a valid physical address when translating them, and the CPU can access the content of such addresses.

Je ne savais pas que les adresses noyau étaient considérées valides par défaut. Comme tu l’as dit, Ksass`Peuk, ils ont peut-être voulu accélérer les choses en évitant de se taper des interruptions de type Page Fault si un programme (utilisateur uniquement ?) venait à accéder directement à une adresse résidant dans l’espace noyau. Car une interruption, c’est coûteux. Ici, il est question de vérifier le niveau de l’anneau de protection et ainsi interdire l’accès au programme ("Segmentation Fault") ou non.

Je continue ma lecture (mais je commence à avoir la caboche qui surchauffe, moi qui adore pourtant ce genre de sujet…).

Cela me fait penser à la discussion sur ce topic. Le patch KPTI induit des problèmes de performances pour éviter de se faire avoir par Meltdown. Je me demande si un noyau à micro-services aurait évité ce genre de mésaventure dès le début puisqu’on est supposé éviter,je pense la lecture "à tout va" de l’espace mémoire du noyau.

Beaucoup d’incertitudes dans mes propos. Désolé.

Allez, dernier truc qui m’a fait rire. Quand je suis allé me renseigner sur les concepts expliqués dans l’article sur Meltdown, notamment l’out-of-order execution, je suis tombé là-dessus : https://fr.wikipedia.org/wiki/Ex%C3%A9cution_dans_le_d%C3%A9sordre

L’auteur des schémas sur cette page n’est sûrement pas inconnu de certains ici. Dommage qu’il ne soit pas ici pour discuter de tout cela avec nous, ça nous aurait sûrement aidés.

Cela dit, j’ai VRAIMENT hâte que @lthms nous dise ce qu’il pense de tout ça…

🦊 - ge0.github.io

+1 -0

C’est là que tu te mets à apprécier tout particulièrement ton Ryzen 5…

Fumble

Je me suis dit exactement la même chose. :ange:

Vu comment AMD chute, ça va leur faire du bien et donc faire du bien à tout le marché. Parce que une entreprise avec un trop gros monopole, c’est pas cool.

Édité par tleb

Je ne savais pas que les adresses noyau étaient considérées valides par défaut. Comme tu l’as dit, Ksass`Peuk, ils ont peut-être voulu accélérer les choses en évitant de se taper des interruptions de type Page Fault si un programme (utilisateur uniquement ?) venait à accéder directement à une adresse résidant dans l’espace noyau. Car une interruption, c’est coûteux. Ici, il est question de vérifier le niveau de l’anneau de protection et ainsi interdire l’accès au programme ("Segmentation Fault") ou non.

Ge0

J’ai pas encore lu les whitepapers pour comprendre les attaques, donc je ne peux pas en discuter dans les détails pour l’instant, par contre, pour cette question, sur ARM, on se ballade en général avec 2 translation tables, une qui contient le mapping mémoire du kernel, et une qu’on change à chaque changement de process userland. Il faut que le processeur sache où est physiquement placé le kernel dans la mémoire pour faire un appel système, donc même quand on est dans le userland, le processeur sais à quelle adresse physique trouver la translation table du kernel. Par contre, toute la mémoire mappée pour le kernel est marquée comme non accessible depuis un niveau d’execution non-privilégié (le userland).

Pour les failles, l’explication de principe de ARM, c’est qu’un branchement prédictif peut récupérer une valeur à laquelle on ne devrait pas avoir accès, et le programme n’y aura effectivement jamais accès, mais si cette valeur est utilisée pour effectuer un autre branchement, en fonction du temps d’accès, on peut déduire à quelle mémoire on a accédé (par exemple en récupérant un bit d’information à laquelle on ne devrait pas avoir accès, on peut faire un branchement vers une page parmi deux auxquelles on a le droit d’accéder, et déduire la valeur du bit à partir du temps d’accès mémoire à chacune de ces pages par la suite). La difficulté est de trouver une routine qui va faire un accès mémoire qu’on va savoir reconnaître et discriminer. A priori, ils ont exploité eBPF pour ça, mais n’importe quelle interprétation de bytecode par le kernel peut être exploitée. Sinon, il faut connaître le kernel à l’avance pour trouver une routine qui fait déjà ce qu’on veut, c’est moins pratique. Y’a d’autres variantes, mais l’idée va toujours être d’observer les résultats des chargements prédictifs de pages de cache ou les comportement des unités de prédictions préalablement entrainées avec les données à faire leaker pour réussir à gratter quelques informations venant d’une mémoire à laquelle on n’a pas accès.

Pour faire leaker du contenu du Trusted Execution Environment (TrustZone), c’est pas forcément aussi simple. Dans l’implémentation que j’ai au bureau, le code TrustZone s’execute directement à son adresse physique, sans MMU, il n’est mappé nul part, et, dans ce mode, il n’y a pas d’execution out of order possible sur ARM, ni même de mise en cache, vu que la mémoire est considérée comme device (un type de mémoire dans le vocabulaire ARM). Pour des implémentations qui utilisent un peu mieux le proc (comme l’implémentation de référence de ARM pour ARMv8A), faire débuter tous les appels au monde secure par une éviction de tout le cache permet d’empêcher de donner accès à des routines dont le temps d’execution indique le résultat (mais ça a une coup en performance). Les patches actuels utilisent à peu près la même méthode pour protéger la mémoire de l’hyperviseur.

Je trouve la courte note d’ARM plutôt claire sur le sujet: https://armkeil.blob.core.windows.net/developer/Files/pdf/Cache_Speculation_Side-channels.pdf

C’est là que tu te mets à apprécier tout particulièrement ton Ryzen 5…

Fumble

Ouai, enfin les failles de Spectre fonctionne aussi bien sur AMD que sur ARM, d’après la FAQ de meltdownattack

+0 -0

[…] Le patch KPTI induit des problèmes de performances pour éviter de se faire avoir par Meltdown. Je me demande si un noyau à micro-services aurait évité ce genre de mésaventure dès le début puisqu’on est supposé éviter,je pense la lecture "à tout va" de l’espace mémoire du noyau.

Ge0

Je pense que ça n’aurait pu changer quelque chose que si (refaire le monde, tout ça) l’architecture en micro-noyau (et même pas micro-noyau hybride comme dans Windows) s’était complètement imposée il y a déjà un certain temps. Auquel cas, on aurait peut-être pas introduit le KASLR. (Et pour Spectre rien n’aurait changé a priori).

Le soucis ici est vraiment que les adresses kernel sont conservés dans un cache particulier pour ne pas avoir à les recharger. Donc même si tu passes sur des micro-services, il n’y a pas de raison que l’on flush plus souvent le cache système : on ne le flush pas de toute façon.

J’ai contacté un pote qui fait la sécu pour avoir un coup de main pour comprendre la mise en oeuvre pour Spectre. Normalement cet article est plus digeste que les white-papers :

https://googleprojectzero.blogspot.fr/2018/01/reading-privileged-memory-with-side.html

Mais je n’ai pas encore eu le temps de le lire.

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein [Tutoriel Frama-C WP]

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte