Pinaraf a écrit 3671 commentaires

Ok, you want the nasty one :)

You have to locate the buggy function with objdump, and replace the whole function with a simple «return -EFAULT;» aka 0xb8f2ffffffc3.
Using objdump -j text on ecdh_generic.ko, there will be two interesting lines :

Idx Name          Size      VMA               LMA               File off  Algn
  1 .text         0000WXYZ  0000000000000000  0000000000000000  00000070  2**4

And

00000000000023e0 g     F .text  000000000000016f ecc_gen_privkey

You will have to patch at address 0x70 + 0x23e0. And just overwrite the function first bytes with 0xb8f2ffffffc3. Then you will have a patched .ko file.
It's a really really really nasty way of patching this. But it works…

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.

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.

À 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é».

Ok, now we have something :)

I did not push strongly my patch because I recently had an hard time trusting my computer (I fear my motherboard may have an issue). Since you have exactly the same bug, yes, a debian bug report would help since the debian team could backport the patch in their kernel, waiting for it to be upstreamed.

Otherwise, well… I'm manually patching my .ko file using an hex editor. That's a weird way to work around the bug, but it's faster than recompiling :)

Just so I can have an idea what may be wrong here, what is your motherboard and what is your CPU ?

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.

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.

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…)

Spectre c'est processus courant. Ou un voisin dans lequel t'arrives à influencer l'exécution du code. C'est pas un accès ouvert à toute la mémoire. Pas comme meltdown qui permet d'accéder à la mémoire du noyau…

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 :

a = 42;
b = 72;
if (tableau[a] < 73) {
  b++;
}

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 stat pour comprendre ça éventuellement plus concrêtement.

# perf stat echo 'toto'
toto

 Performance counter stats for 'echo toto':

          0.354665      task-clock (msec)         #    0.010 CPUs utilized          
                 1      context-switches          #    0.003 M/sec                  
                 0      cpu-migrations            #    0.000 K/sec                  
                59      page-faults               #    0.166 M/sec                  
         1,303,535      cycles                    #    3.675 GHz                    
           765,605      instructions              #    0.59  insn per cycle         
           154,395      branches                  #  435.326 M/sec                  
             7,829      branch-misses             #    5.07% of all branches        

       0.034129737 seconds time elapsed

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 ?

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.

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.

Les patchs protègent le binaire compilé heureusement, ce n'est pas des patchs à appliquer sur le binaire «assaillant».

Tu voulais dire popcoin ?

Certaines mesures d'hygiène informatique (souvent casse-couilles) diminuent considérablement l'impact tout de même.
Pour meltdown, les détenteurs de CPU Intel n'ont pas le choix, mise à jour du noyau et activation de KPTI…
Pour spectre, sur nos machines perso, la plus grosse attaque possible serait du code JavaScript qui va lire la mémoire du navigateur web (et donc des infos sur les autres sites). Je me sens moins concerné, j'utilise en permanence 4 instances de navigateur web, selon le type de site visité et la sensibilité des données qu'il manipule. Pour à travers spectre voler des infos sur mon compte bancaire, il faudrait que, depuis son domaine (NoScript bloquerait le reste), une de mes banques en attaque une autre.
De manière générale, il serait temps de se demander pourquoi on laisse n'importe quelle page web exécuter du code sur nos machines. Est-ce-que ça en vaut vraiment la peine ?
Et pourquoi Google a laissé pendant tant d'années (et semble continuer encore) des fabricants de smartphone vendre des Android sans garantie de maintenance sur la durée ?

Why in english ? This is a french website, quite unusual to see an english comment here.

I contacted the crypto subsystem maintainers a few days ago to know how to boost this. Do you have any Debian bug report regarding this ?

FR : J'ai contacté les mainteneurs de la partie crypto il y a quelques jours pour savoir comment pousser le patch… As-tu un rapport de bug debian à propos de ce soucis ?

Toutes les autres contre-mesures ? De quelles contre-mesures parles-tu ? Ça ne désactive que le KPTI…

PCID/INVPCID permet d'implémenter KPTI avec un coût moindre. La faille serait présente depuis avant l'introduction de cette fonctionnalité, certains affirmant même qu'elle date du Pentium 1…

Plus précis mais aussi plus spéculatif. J'ai choisi (en plus il était tard) de ne pas mentionner ces pistes, même si le point d'AMD semble vraiment fiable.

Mais dire «D'après AMD, il s'agirait d'un manque de contrôle lorsque le processeur empile de manière prédictive (speculative) les instructions avant de les exécuter (pipelining).» est incomplet/incorrect. On ne peut pas expliquer cette faille juste en prenant ce point de vue, il faut a priori partir très bas dans le fonctionnement du CPU, la faille serait au niveau du cœur d'exécution des micro opérations et pas de l'exécution des instructions x86 à proprement parler (sinon ça serait corrigeable par microcode).

Donc attendons la levée de l'embargo à la con qui ne protège personne et ne fait que propager inquiétudes et rumeurs…

Sont-ils plus récents que des Pentium 1 ? Si oui, il y a une chance pour qu'ils soient impactés :)

+1

Sachant que même une faille vicieuse comme rowhammer a fini par être exploitée en Javascript, je vais continuer à n'activer le JS sur internet que sur les sites de confiance…

J'aime bien ta formulation. Et c'est pour ça que j'ai juré le jour où Apple a abandonné ses PowerPC pour passer à du x86, la demande étant très faible les prix sont élevés…

Le bug semble être localisé dans la partie «hard» du processeur, pas celle sous contrôle du microcode. Sinon il n'y aurait pas tout ce tintouin et on nous demanderait juste de mettre à jour nos microcodes.
Par contre l'amélioration des performances du patch… Ça va être dur, le TLB se fait défoncer obligatoirement, et c'est ce qui coûte cher.

Les usages avec beaucoup d'appels système… C'est vague :)

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)…
Le pire c'est les bases de données.
Tout ce que tu cites par contre consomme du processeur mais sans faire trop d'appels système (si c'est bien codé), donc c'est peu impacté.

Il est urgent d'attendre :)

Tu auras bientôt une mise à jour de sécurité concernant le noyau. Tu devras l'appliquer, comme toute mise à jour de sécurité. Et tu perdras de 3 à 5% de performances sur certains usages précis.

Si si, on peut le désactiver par un paramètre au boot, pti=off / pti=on.
Là c'est pour «marquer» le CPU comme ayant un bug et donc imposant d'activer par défaut le PTI. La valeur initiale quoi…