Pinaraf a écrit 3682 commentaires

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…

Ou du POWER9 ? https://www.raptorcs.com/TALOSII/prerelease.php

C'est désactivable, mais est-ce «désactivable» ? :)
On peut par un paramètre au boot le désactiver. Mais si la faille permet la lecture de tout l'espace noyau, ou pire la moindre écriture, c'est inenvisageable de la désactiver à part sur un système parfaitement clos…

Phoronix a fait un premier benchmark (je suis pas fan, ils auraient pu faire plus propre mais ça donne une idée) : https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1

Les résultats font vraiment peur surtout pour le DBA que je suis…

Tu peux remontrer ? Je suis pas sûr d'avoir bien compris…

Firefox 6.0.2 ? J'espère qu'il y a une fuate de frappe… :)

Je viens de faire quelques recherches, le gros du noyau est quasiment compilable avec LLVM/Clang. Il reste quelques patchs, mais par contre les pilotes sont loin d'être tous testés… Donc pour quelques systèmes embarqués ça doit être jouable, pour un noyau générique par contre c'est pas encore ça…

Quand on lance un scan-build ou SonarQube sur un kernel ça donne quoi comme nombre d'alerte de ce genre : c'est monstrueux/énorme/pas-si-pire/ça-va/RAS/c'est-pas-si-simple ?

Il faudrait que le noyau compile avec Clang/LLVM pour scan-build. C'est un morceau de code quand même bien complexe, il a des dépendances légitimes à des extensions de GCC qui ne sont pas nécessairement implémentées par clang. Le projet LLVMLinux étant semble-t-il en sommeil pour le moment, les patchs ne sont pas à jour de ce côté.

D’ailleurs question technique pour SonarQube : le warning est levé tout simplement parce que la variable err est écrasé sans être utilisé ou bien il y a des mécanismes en plus ?

Je ne sais pas pour SonarQube, mais pour LLVM c'est parce que err est écrasé. C'est le seul warning levé pour le code suivant, qui correspond globalement à ce que fait au final le noyau pour le compilateur (j'ai pris stat comme fonction dont le résultat ne peut être déterminé par le compilateur)

#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>


int *toto = NULL;


int foo (const char *p) {
        struct stat statbuf;
        if (stat(p, &statbuf) != 0) {
                return -1;
        }
        toto = malloc(sizeof(int));
        return 0;
}

int zaz (int *a) {
        *a = 42;
        return 0;
}

int bar () {
        int err = 0;
        if (foo("/tmp/patate") != 0)
                err = 1;
        err = zaz(toto);
        return err;
}

Ou dire aussi «chomeureuses»

Le MEDEF désapprouve ce message.

Bref, c'est de la bullshit de militants pseudo-linguistes.

De militant·e·s. Tu vas les fâcher sinon :)

Idem pour scan-build (l'analyseur statique de LLVM) qui le classe également en warning…

Raté, ça serait plutôt « arquerre in boulangeu pour faire du pain ». Mais tout cha ch'est des bablutes, in peut flaminquer des heures comme cha…

Oui, ce type d'outil devrait lever une alerte. Mais le compilateur aussi devrait dire qu'il se passe quelque chose d'étrange.
Mais pour la défense des développeurs, les outils comme coverity, ou certains avertissements du compilateurs, sont difficiles à suivre :
- ils ont tendance à produire des faux négatifs
- les développeurs n'ont pas nécessairement tous les accès aux outils quand ils sont propriétaires (coverity) ou non officiellement supportés (les avertissements de clang diffèrent de ceux de gcc)
- sur le nombre de lignes de code du noyau, il reste beaucoup de rapports à trier
- comment les développeurs pourraient-ils tester ces outils sur leurs dépôts tiers ? A priori coverity ne teste que le noyau 'officiel' de Linus, ils ne peuvent pas savoir avant d'intégrer un commit s'il va augmenter le nombre de rapports. Et même avec un outil d'analyse libre que les devs pourraient lancer eux-même, ces outils sont souvent assez longs, surtout sur une telle base de code…

Pour le coup, je pense que c'est au compilateur de faire un avertissement devant un tel code. Mais il se mettrait sûrement à faire des tas d'avertissements sur par exemple du code généré… Équilibre délicat, je souhaite ne jamais bosser sur un compilateur existant pour ne pas avoir à gérer ce genre de choix entre la peste (ne pas avoir l'avertissement) et le choléra (casser du code existant).

Bonjour

Je n'ai pas fait de debug interactif (c'est loin d'être facile sur un noyau et mériterait un journal à part entière). J'ai uniquement utilisé gdb, sans être root, comme un joli désassembleur affichant le code C correspondant en même temps. Le code n'a pas été exécuté par le noyau.
Et j'ai préféré travailler sur la 4.13 parce que je savais que la régression y avait été introduite, j'ai préféré éviter un éventuel «empilement» de problèmes au cas où la 4.14 introduisait d'autres bugs.

Yep, bien sûr. J'ai même été plus bourrin sur les nouveaux noyaux debian : flemme de recompiler, donc je patche le fichier à coup d'éditeur hexadécimal pour injecter un return -EFAULT; à la place de la fonction.