Mon bureau en mode noyau

Non, non, vous ne verrez pas dans cet article de screenshots du noyau ! J’ai juste envie de poster ici une capture d’écrans que j’ai réalisée et commentée il y a quelque temps. J’étais à ce moment-là en train de réaliser un des mes développements noyau les plus conséquents et cela m’avait conduit à industrialiser mon environnement de travail pour effectuer développements et tests de la manière la plus efficace possible.

Voici donc la capture :

Espace de travail

La résolution est assez élévée puisque mon bureau est constitué d’un écran 19” et d’un 22” placés côte à côte en mode twinview.

Le 22 pouces me permet d’utiliser confortablement un gvim ouvert sur 2 colonnes. Je peux ainsi éditer un fichier en lisant la documentation, ou bien comparer deux fichiers facilement. Sur le 19 pouces de gauche, j’ai fait tourner :

  • le shell pour la compilation du noyau
  • virtualbox pour les tests de modification noyau sans les reboot de machine physique
  • giggle pour l’analyse du patchset en cours de préparation

Je pouvais ainsi étudier les crashs ou les problèmes noyaux tout en lisant le code pour trouver mes erreurs.

Contribution au libre, 2009 commence fort.

Du côté de mes contributions au logiciel libre, l’année 2009 commence assez fort. Il semble que j’ai réussi à déclencher une petite révolution.

Le système de test de NuFW avait mis en évidence un crash rare, non reproductible facilement dans nuauth, le serveur d’authentification de NuFW. Les sorties de gdb ou valgrind révélaient un problème absurde dans la bibliothèque cyrus-sasl. NuFW l’utilise pour réaliser la phase d’authentification des utilisateurs. Le crash apparaissait lors d’un appel à sasl_dispose() qui est la fonction à appeler lorsque l’on a terminé la phase d’authentification. Après maintes vérifications et plusieurs dizaines d’heures de debug, j’étais convaincu que nuauth, le serveur d’authentification de NuFW, utilisait la bibliothèque de manière correcte et que le code environnant était correct.

Lorsque l’utilisation d’une bibliothèque est légitime et que l’on obtient un plantage, c’est que l’on a trouvé un bug. J’ai donc alors commencé à enquêter sur Cyrus-sasl. Cette bibliothèque est développée dans le cadre du projet cyrus (serveur de mail imap) par la Carnegie Mellon University. Elle est utilisée par un nombre conséquent de logiciels libres fameux (dont openldap, sendmail). Même si sendmail a une réputation sulfureuse de sécurité, il est connu pour sa stabilité. Et donc, en me lançant dans le debug de ce problème début septembre 2008, je savais que je m’attaquais à quelque chose de robuste car très utilisé. Le bug allait donc être complexe à trouver.

J’enchainais alors des séances de deboguage plus ou moins longues passant à certain moment plusieurs longues journées de travail (lire 14 ou 15 heures) sur ce problème. Je sortais tout de même victorieux de la confrontation et le 20 septembre 2008, j’envoyais un message à la liste de diffusion cyrus-sasl : [PATCH] Fix problem with sasl_set_mutex

NuFW utilise les bibliothèques cyrus-sasl et libldap_r et libldap_r utilise lui aussi cyrus-sasl. Elle s’en sert lors de la phase d’authentification sur la base LDAP. Comme, et libldap_r et NuFW sont multithreadés ou multithreadable, ils initient tous les deux la bibliothèque cyrus-sasl pour le support des threads. Il y a notamment un appel à sasl_set_mutex() qui définit l’implémentation de mutex à utiliser. NuFW appelle cette fonction avec ses propres paramètres et libldap_r fait de même (même lorsque l’on fait un bind simple, les connaisseurs apprécieront). Or sasl_set_mutex() ne détectait pas qu’une initilisation avait déjà été faite. On avait donc un conflit possible. Les fonctions de mutex sasl prennent des paramètres void* en entrée et travaille sur ces pointeurs. Il y donc potentiellement des casts dangereux.

Dans le cas de NuFW, le problème était beaucoup plus radical. L’initialisation de libldap_r se fait lors du chargement du module ldap de nuauth. Par conséquent, c’est la fonction ldap qui est utilisée après chargement du module. Or, nuauth peut changer de configuration et donc de modules à chaud. Il réalise notamment un déchargement des modules. Or, cela ne met pas à jour la fonction mutex de sasl qui appelle donc une fonction déchargée. Ceci conduit immanquablement au crash. Cette fonctionnalité de modification de configuration à chaud est massivement utilisé dans le système de tests de NuFW et c’est donc pour cette raison que le crash ne se produisait qu’à cet endroit.

J’aurais du déboguer plus rapidement ce problème. La piste que j’aurais du voir plus tôt était l’utilisation de fonctions stockées à des emplacements mémoires non valides. Cette information était donnée par gdb et j’aurais du lui faire d’avantage confiance.

Ma remontée de bug et mon patch ont rapidement été pris au sérieux et un patch implémentant mon idée a été commité dans les sources : Fixed sasl_set_mutex() to disallow changing mutex management functions once sasl_server_init/sasl_client_init is called

J’étais content de voir ce correctif appliqué, mais vu la criticité pour NuFW, j’aurais été satisfait de voir arriver une nouvelle version de cyrus-sasl fixant ce bug. Le problème étant déclenché par une utilisation précise de la bibliothèque, je n’étais pas en droit de remonter mon exigence. De plus, la dernière version de cyrus-sasl date du 19 mai 2006 et je me doutais donc que je n’allais pas être entendu.

Début janvier, un mail envoyé sur la liste a pointé le fait que le bug était reproductible en utilisant le stockage des mots de passe sasl dans ldap : En utilisant lui aussi la bibliothèque libldap_r cyrus-sasl se mordait la queue. Le bug était donc aussi interne à cyrus-sasl. Fort de cette conclusion, j’envoyais une réponse au message signalant le problème :

This made the bug self contained and not dependant of other applications. Given the fact that the effect of this bug is a crash of the calling program, it could be interesting to release a new version of the sasl library. (my 0.02$)

J’avais ainsi osé demandé une nouvelle version sur un logiciel où je n’avais pas écrit une ligne de code. À ma surprise, cela s’est conclu par ce message :  Next release of CMU SASL – call for favorite bugfixes où un membre de l’équipe de développement annonce l’arrivée probable, aux alentours du 15 février, d’une nouvelle version de la bibliothèque et demande quels sont les corrections de bugs que les utilisateurs voudraient voir figurer dans cette version.

Je commence donc l’année 2009, en réussissant à déclencher la sortie d’une nouvelle version d’une bibliothèque qui n’avait pas eu de nouvelles versions depuis près de trois ans !

Je conclus ce poste en plagiant pollux et en revoyant mes objectifs de contributions à la hausse pour l’an prochain :

En 2010, je déclenche une sortie de Debian.

Total annihilation (version C)

Bon, je m’amuse en ce moment à rajouter une fonctionnalité à snort-inline. En finissant mes modifications, je suis tombé sur le morceau de code suivant :

/* Check to see if we got a Reinjection rule or not */
if(!pv.ipfw_reinject_rule)
{
pv.ipfw_reinject_rule = 0;
}

Pour les non développeurs c’est un peu l’équivalent de :

Si t’es mort, meurt encore

Tient, ça pourrait faire un titre de James Bond.

Contre pub openoffice, la suite

Étant à cours d’idée, j’ai soumis la contre publicité Openoffice.org à la sagacité des lecteurs de Linux en postant un journal.
Il est remonté plusieurs idées intéressantes. L’une des idées principales a été de rendre le message plus explicite et d’éviter tout sexisme. L’essai suivant règle les deux points :
Offrez des cadeaux
Offrez des cadeaux

On m’a aussi proposé une version plus geek :

Offrez des cadeaux à votre PC
Offrez des cadeaux à votre PC

Voilà, je mets à disposition le XCF pour ceux qui veulent construire sur cette base : pub-openoffice.xcf

Merci à tous pour les nombreux retours !

C’est aussi bien qu’avant

Tout est parti d’un caprice de mon ordinateur fixe :

Si tu me rebootes ou si tu m’arrêtes, je ne me rallumerais que dans 24h

Après avoir tenté de raisonner à coups de tournevis, je lui ai dit :

Babe, I’m gonna leave you

Ce qui donne en français :

Je file t’acheter un successeur !

Je cours donc guerrier à montgallet pour aller dénicher un nouveau PC.

Mon choix se porte sur un montage à base d’une carte mère Asus P5Q et d’un processeur Intel  E8500. Confiant après avoir ubuntuifié un certain nombre de machines récentes sans me poser la moindre question, je n’ai même pas vérifié la conformité des composants. Le plaisir de la surprise n’en a été que plus grand.

La carte réseau n’est pas reconnue, heureusement il y a cette page qui indique la marche à suivre. Pour info, le noyau 2.6.27 supportera la carte en natif mais le pilote est noté comme expérimental (il faut activer “Atheros L1E Gigabit Ethernet support” dans la liste des cartes Gigabit).

Les disques ne sont reconnus que si l’on sélectionne AHCI comme mode de présentation des disques par le BIOS.

Enfin pour avoir des informations par lm-sensors sur la carte mère, il faut tout d’abord au moins la version 0.72 et un noyau 2.6.25. La fin de l’astuce est sympathique :

sudo modprobe w83627ehf force_id=0x8860

En bref, il suffit de dire au noyau que

Mais si ! tu n’as pas été présenté mais je le connais. Fait lui confiance, c’est un ami.

Pour ce qui est des infos CPU, il suffit d’avoir un noyau supérieur à 2.6.25 pour récupérer ce qu’il faut.

Bref, ça a été un grand moment de revival du début des années 2000 !

Cependant, si l’on regarde de plus près :

  1. Je n’ai passé qu’une soirée sur le problème et pas une semaine complète. Merci les forums et les utilisateurs plus nombreux et compétents.
  2. Le matériel utilisé est vraiment récent et il est déjà supporté dans Linux alors qu’il aurait fallu plus d’un an auparavant
  3. Les pilotes ont été poussés par les fabricants dans le noyau (si l’on excepte la puce winbond où les specs n’ont pas l’air d’avoir été reçue par les développeurs).

Il y a donc une amélioration notable grâce à une accélération notable de l’arrivée des nouveaux pilotes dans le noyau et un support par les forums et les blog bien plus efficace qu’avant.

Lutter contre la faille DNS avec Netfilter

La découverte récente d’une méthode permettant d’exploiter des failles dans la plupart des implémentations DNS à fait beaucoup de bruits. J’en tiens pour preuve des articles dans ZDNET (Colmatage d’une faille de grande envergure sur les serveurs DNS), Le Monde et les échos.

Si l’on étudie ce qu’écrit le CERT dans l’article Multiple DNS implementations vulnerable to cache poisoning, une méthode de contournement de la faille consiste à rendre aléatoire le port source utilisé pour les requêtes DNS.

Lors de recherches faites sur le bloquage de Skype, j’avais implémenté la traduction d’adresse avec attributions de port source aléatoire dans Netfilter et Iptables. Cette modification avait été faite pour empêcher l’établissement de connexions directes entre deux machines situés derrière des routeurs malgré la traduction d’adresse. Cette fonctionnalité est disponible dans Linux depuis le noyau 2.6.21. Elle peut-être utilisée pour lutter contre la faille DNS.

Si les serveurs DNS relais ou les clients se trouvent derrière votre pare-feu Netfilter, il suffit de rajouter la règle de NAT suivante :

iptables -I POSTROUTING -t nat -p udp --dport 53 -j SNAT --to IP --random

Netfilter va alors rendre aléatoire le port source des connexions DNS tel qu’il est vu derrière la passerelle (et donc pour le monde extérieur) luttant ainsi contre les attaques de cache poisonning.

L’art du commit

Lors du Netfilter Workshop 2007, j’ai eu le plaisir de revoir Patrick McHardy et la chance de rencontrer David Miller (Davem) le mainteneur de la couche réseau de Linux.

Patrick envoie assez souvent des séries de patchs impressionnantes à Davem pour demander leur intégration dans le noyau officiel. L’ensemble des contributions des développeurs de Netfilter qui est ainsi transféré lors de ces envois.

Lors d’un des repas, j’ai cité à Davem l’un des plus gros envois de Patrick et je lui ai demandé ce qu’il ressentait lorsqu’il recevait une telle série de patchs. Sa réponse a été rapide :

Je sais que ma journée est finie

Son sourire en disant cela m’avait marqué et je viens de le comprendre en lisant le dernier envoi de Patrick.

Le premier mail de la série est intitulé :

[NETFILTER 00/49]: Netfilter update

Il comporte notamment une série impressionnante de 35 patchs de la main de Patrick. Parmi ceux-ci un gros travail effectué sur nfnetlink_queue, sujet dont je m’occupe particulièrement. J’ai donc relu l’ensemble des patchs pour voir de quoi il en retournait.

Le découpage des patchs est minutieux, chacun est la réponse à un objectif simple clairement précisé dans l’en-tête du mail. Si l’explication n’est pas suffisante, celle-ci est complété par un texte plus long qui avance les raisons des modifications. Prenons par exemple le patch 46. Le mail correspondant commence par :

[NETFILTER]: nfnetlink_queue: remove useless enqueue status codes

The queueing core doesn’t care about the exact return value from
the queue handler, so there’s no need to go through the trouble
of returning a meaningful value as long as we indicate an error.

Le sujet avance l’idée globale et le paragraphe suivant explique clairement les motivations. Comme le patch comporte uniquement cette modification, il est facile de le lire pour comprendre comment cela a été fait et si cela l’a été bien.

Je comprends donc bien le sourire de Davem, travailler avec quelqu’un comme Patrick McHardy est un régal. Un exemple à montrer dans toutes les écoles.

Sarkozy, tueur de TuX

L’initiative candidats.fr a été un succès mais le candidat Sarkozy n’a pas répondu au questionnaire malgrè son engagement lors de Solution Linux. Il brise ainsi une promesse avant même la date de l’élection.

Dans le même temps, le discours tenu par les représentants du candidat UMP font peur, notamment en ce qui concerne la loi DADVSI :

La protection du droit de propriété est essentielle pour Nicolas Sarkozy, et sa conviction est inébranlable en la matière. Nous ne considérons pas aujourd’hui que les droits des consommateurs soient lésés.

J’en appelle donc à la responsabilité de chacun. Votez à l’élection présidentielle, il pourrait tenir certaines promesses!

Sarkozy tueur de Tux

Logiciels libres : drogue douce ou drogue dure ?

La sortie du bureau Free-EOS 2.0 vient d’être annoncée mais je m’interroge sur la pertinence d’une telle approche en 2006.

Le bureau sous GNU/Linux est maintenant une alternative sérieuse au bureau estampillé Microsoft. N’est-il pas temps de promouvoir le changement d’OS plutôt que de promouvoir l’utilisation du libre sous OS propriétaire ?

En faisant des Logiciels Libres une drogue douce que l’on prend de temps en temps pour s’aérer l’esprit, on le canalise et on ne permet pas à ce qu’il attaque suffisamment le cerveau. Pour moi, il doit devenir une drogue dure : quelques prises de LiveCD et on finit par installer GNU/Linux contraint par la qualité de l’outil.

Le port vers windows des applications libres est compréhensible : les développeurs veulent élargir leur base d’utilisateurs, toucher plus de monde. Mais, ils ne voient plus assez loin ou sont en tout cas trop impatients. Les OS libres sont prêts à s’imposer sur le poste de travail, il faut les y aider en les transformant en une alternative à considérer car elle apporte un plus fonctionnel indéniable.

En cela, le port des applications est le mal puisqu’il nivelle les expériences. Je rêve qu’une application exceptionnelle et grand public ne soit disponible librement que pour OS Libre. Cela encouragerait le développement des logiciels libres de manière prodigieuse.

Des paquets poupées russes ?

La seule différence entre des paquets IP et des poupées russes, c’est qu’il faut être un geek pour connaître et apprécier l’encapsulation IP qui est souvent transparente pour l’utilisateur.
J’ai récemment réalisé une configuration me permettant de relever mes mails depuis une connexion WiFi anonyme. Le cahier des charges est simple, je ne veux pas toucher à la configuration de mon logiciel de mail, et je ne veux pas ouvrir de port sur mon firewall depuis le VPN. Plusieurs étapes sont donc nécessaires pour parvenir à mes fins. La succession des encapsulations et transformations réseaux est alors la suivante :

  1. REDIRECT netfilter pour rediriger les paquets du client mail vers un port local
  2. Forward ssh des ports redirigés sur localhost vers les ports des machines concernées
  3. lien openvpn supportant la connexion ssh (en udp port 53 pour faire simple)

Si on rajoute à cela l’encapsulation des paquets du lien ADSL qui est sans doute du L2TP donc de l’IP encapsulée dans UDP, on atteint un certain niveau d’encapsulation, et encore la description ne quitte pas la couche protocolaire 😉