Pinaraf a écrit 3671 commentaires

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.

Ha ben ça juste boote, c'est mieux, non ? :)

Désolé pour le temps de réponse, j'ai été très négligent avec ce journal et j'ai manqué de temps à y consacrer (boulots, maladie, tout ça tout ça)

«ma carte mère n'a pas le nécessaire pour sauvegarder un kernel panic hélas» : les cartes mères de serveurs ont un espace mémoire disponible, exposé en ACPI, qui permet au système de stocker des données en cas de crash.
Cf https://lwn.net/Articles/434821/

Sinon la clé est générée par le noyau pour vérifier sa compatibilité avec certaines normes de sécu (du FIPS…). Je n'ai pas creusé plus.

Yep, j'ai hâte, pour le moment je démarre ma machine en patchant à l'éditeur hexadécimal le .ko des derniers noyaux debian (c'est plus rapide d'écrire au bon endroit b8f2ffffffc3 que de recompiler le noyau, quand même).

Ouais mais ils sont quand même assez ouverts sur l'ajout de nouvelles fonctionnalités pour pouvoir réimplémenter les extensions. Donc compatibles Chrome mais aussi avec des fonctionnalités bonus.
De toute façon au bout d'un moment ils ne pouvaient plus trop avancer sans devoir casser cette partie là du navigateur. Et la majorité des utilisateurs a choisi depuis longtemps les performances contre l'extensibilité, donc pour rester vivant Firefox n'avait plus trop le choix…

Merci pour ce projet !
Une question que je me pose par rapport au projet NERF : que devient là dedans l'ACPI ? Est-ce-que l'OS 'client' peut s'en passer en utilisant à la place des mécanismes comme le device tree d'OpenFirmware ? Ou le noyau Linux remplaçant l'UEFI fournit-il ses propres tables ACPI et cie à l'OS ? Ou l'ACPI reste-t-il sans intervention du noyau Linux embarqué dans le NERF ?

J'ai pas dit que je n'avais que des rudiments de C, j'ai dit qu'il faut que des rudiments pour comprendre le code impacté :)
Pour le processus de développement du noyau, j'ai copié depuis moi-même y'a 7 ans… https://linuxfr.org/users/pied/journaux/de-l%C3%A9criture-dun-pilote-linux-pour-un-gadget-suite

Beaucoup d'outils dépendent encore d'iptables. iptables et nftables ne peuvent pas être utilisés en même temps.
Et la stabilité de nftables est très récente, c'est que depuis Debian stretch que le paquet est dans stable.
Mais effectivement, ça promet de changer beaucoup de choses, il était plus que temps !

Je ferai ça dans un prochain journal alors, quand j'aurai commencé à vraiment exploiter SELinux pour castrer des applications dangereuses…
Par rapport à nftables : it works… Et ça fait plaisir d'avoir un ensemble qui soit lisible et qui gère à la fois IPv4 et IPv6.

Ho la belle boulette… Faut plus que je rédige de journaux le soir, merci.

Toutes mes excuses, j'ai oublié les liens…

Pour le bug OCaml/Intel : http://ocamllabs.io/general/2017/06/26/IntelHyperThreadBug.html

Pour les failles de sécu, on en a vu plusieurs, comme la memory sinkhole de 2015.

Heu, non, Java uniquement. Je viens d'explorer toute l'archive pour vérifier, c'eut été une nouveauté intéressante.