Victor STINNER a écrit 1632 commentaires

Quelques articles
* The Big Kernel Lock lives on (May 26, 2004) : Article de corbet
* tty: BKL pushdown (8 Feb 2008) : email (patch) de d'Alan Cox
* The big kernel lock strikes again (May 13, 2008) : Article de Jonathan Corbet
* "kill the Big Kernel Lock (BKL)" tree (14 May 2008) : email d'Ingo
* Removing the Big Kernel Lock (May 15, 2008) : Article par Jeremy (Kerneltrap)
* Kill BKL Vol. 2 (May 21, 2008) : Article de Jonathan Corbet

Ingo maintient une branche git (enfin, il me semble que ça soit une branche) qui vise à supprimer le BKL, c'est-à-dire utiliser plusieurs petits verrous pour chaque sous-système :
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.(...)

La suppressin du BKL dans ReiserFS a montré un gain significatif de performances.
http://www.linux-magazine.com/Online/News/Reiserfs-Experienc(...)

Pendant ce temps, FreeBSD supprime progression son BKL avec le travail du groupe SMPng, dont le travail a débuté en 2003.
http://www.freebsd.org/smp/#status
« While limited sections of the FreeBSD kernel still require Giant, especially more obscure device drivers and file systems, most parts of the kernel now neither require nor run with the Giant lock »

À priori, FreeBSD est plus en avance que Linux au sujet du BKL.

Linux Magazine contient des articles similaires sur les dernières nouveautés du noyau. Mais je ne crois pas que les articles soient écrits par patrick_g.

@patrick_g : LinuxMag paie (bien ses auteurs), à toi de voir ;-)

Par contre, j'ai beau cliquer sur mon LinuxMag, Firefox ne réagit pas. C'est un peu nul le papier.

GCC 4.2.1 est sorti en juillet 2007 (il y a plus de deux ans). Il aurait été plus intéressant de tester GCC 4.4. À ce que j'ai compris, c'est juste qu'ils avaient la flemme : ils ont pris la version de LLVM-GCC livrée avec Xcode (3.2 de Mac OS X 10.6).

La compatibilité binaire est pénible si on veut rajouter des machins à Phonon

Tiens bizzare, j'avais entendu que la principale raison pour laquelle KDE a développé Phonon est qu'ils ne voulaient pas être dépendant du cycle de release Gstreamer. Autrement dit, Gstreamer était trop instable (niveau API) pour KDE.

J'ai toujours trouvé cette excuse super pourrie, et maintenant je lis que Phonon a une API trop stable !?

Phonon est selon moi trop jeune pour que l'API/ABI soit déjà fixé.

Encore une fois, je ne comprend pas pourquoi Phonon a été écrit. Vu que Phonon a écrit après Gstreamer, il est forcément plus jeune, moins complet, etc. (dumoins au début)

--

À côté de ça, il y a pulseaudio. Autre surcouche super pourrie qui est bourré de bugs (les derniers exploits noyau utilisent une faille PulseAudio qui est en suid !?), plus limité que ses backends (pas d'accélération matérielle à ce que j'ai entendu), etc.

Pourquoi ne pas utiliser Gstreamer partout ? Je crois que c'est le syndrôme NIH qui a encore fait des victimes.

« Conformément à la politique de la Région [Poitou-Charentes], tous les codes sources liés à ce projet sont publiés sous licence GNU GPL. »

Génial ! Très chouette politique. Vivement que ça soit fait au niveau national.

Je me suis abonné pour ~60€/an. Vu la qualité des articles (excellente), je pense que c'est un bon investissement :-) Je lisais déjà les LWN gratuitement depuis qq. temps. Les articles sont toujours bien vulgarisés (pour un développeur, pas pour Mme. Michu bien sûr), court (concis) et bien rédigés.

Ah tiens, je m'étonnais églalement de ne pas recevoir le livre Ruby. D'autant que j'ai déménagé, je craignais donc que le livre se soit perdu :-( Enfin, je pense qu'il va bien finir par arriver.

Keyboard error: press F1 to continue

Si j'avais l'esprit tordu, je dirai que le logo fanal ressemble à un goatse. Mais il n'en est rien.

Donc non, elle n'est pas libre (on ne peut pas redistribuer ses modifications) et en plus elle sent bon l'amateurisme.

C'est pas Google ou Free qui avait une licence similaire ? (la licence peut changer dans le temps, et vous acceptez déjà la future licence que vous n'avez pas encore lue)

Le noyau 2.6.11 faisait environ 6,6 millions de lignes alors que le 2.6.30 en fait environ 11,5 millions (aux esprits chagrins qui crierait au bloat je recommande la (re)lecture de la présentation 2006 de Greg KH. Vous y trouverez la phrase "Linux supports more devices out of the box than any other operating system ever has" qui vous clouera le bec).

Hum, en même temps, il y a pas mal de pilotes qui ne sont plus utilisés par personne. À ce que j'ai lu, une fois qu'un pilote est intégré dans le noyau, il est maintenu à perpétuité... Mais en même temps, s'il n'est plus testé, je doute qu'il survive à tous les changements d'API ...

Et cette réécriture elle est dispo dans un version stable de FreeBSD ou bien elle fera juste partie de la future release 8.0 ?

En cherchant rapidement, je n'avais pas trouvé l'info. En y regardant mieux : oui, le nouveau tty sera à coup sûr dans FreeBSD 8.0 :
http://ivoras.sharanet.org/freebsd/freebsd8.html

MPSAFE TTY

Status: Committed to -CURRENT
Will appear in 8.0: sure
Author: Ed Schouten

Ed Schouten a réécrit TTY. La nouvelle implémentation n'utilise le Big Kernel Lock par exemple. Elle a été mergée dans FreeBSD le 20 août 2008.
http://lists.freebsd.org/pipermail/freebsd-arch/2008-August/(...)
http://80386.nl/blog/
http://wiki.freebsd.org/TTYRedesign
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2008-02(...)

Parfois il vaut mieux jetter le vieux code et en réécrive du neuf, tout simplement parce que plus personne ne sait maintenir l'ancien.

Je ne pense pas qu'on puisse comparer le pilote Hyper-V et le pilote Nvidia. Le pilote Nvidia embarque beaucoup de secrets industriels sur la conception de la puce (GPU), des algorithmes de compression, des optimisations, etc. Et puis, il faut pas oublier que dans des boîtes comme Nvidia, il a beaucoup d'avocats payés pour défendre les brevets et la propriété intellectuelle. À quoi bon déposer des brevets si c'est pour que des crypto-communiste volent des années de R&D ? :-)

Un exemple chez HP : les imprimantes sont parfaitement supportées

Je pense que pour l'impression, l'intelligence est surtout dans l'imprimante, alors que pour une carte graphique, l'intelligence est beaucoup dans le pilote logiciel. Il y a pas grand chose à cacher dans le pilote d'une imprimante. Allez, au mieux des bidouilles pour vider plus rapidement les cartes d'encre officieuses (DRM sur les consommables \o/) ou des identifiants uniques utilisés par les services de police pour démasquer les faussaires.
http://www.eff.org/issues/printers

Je pense que tu devrais ouvrir un ticket pour chaque bug que tu as noté, puis espérer que ça soit rapidement corrigé ;-) L'équipe de développement semble motivée.

Un objet "tun" utilise la structure tun_fops (de type "struct file_operations") qui contient des callbacks vers les fonctions appelées lors des différentes opérations sur le fichier /dev/net/tun. L'exploit utilise l'opération "mmap" sur le fichier tun. Si j'ai bien compris, l'idée est d'écraser tun_fops->mmap pour le faire pointer vers une fonction située à l'adresse 1. À cet adresse, l'exploit écrit le code machine de l'instruction "CALL <own_the_kernel>". Enfin, la fonction own_the_kernel change l'utilisateur du processus (pour passer root).

L'exploit est assez compliqué, alors je suis pas sûr de ce que je raconte. Mais bon, ça te donnera une meilleure idée de ce qui se passe.

Bug dans la fonction personality()

Ce bug a été corrigé le 26 juin dans la version git du noyau Linux :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)

Petite histoire du bug et de son correctif par Julien Tinnes :
http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.htm(...)

Bien que je pense que parmi tout ce qu'il raconte, il y a une part de vérité, le ton utilisée par Brad n'est pas le plus approprié pour discuter avec les développeurs. Ses critiques ne me semblent pas très constructives. Il ne propose pas de solution pour évaluer la criticité d'un bug noyau par exemple. Il se vante de contourner SELinux, AppArmor, LSM, l'audit, et son exploit utilise des failles dans Pulse Audio et personality(). Est-ce qu'il propose un correctif ou une bien une procédure pour éviter d'autres bugs similaires ? Non, il se contente de se moquer ouvertement des développeurs noyau...

La faille est également présente dans le noyau de test version 2.6.18 de RHEL5 (le patch introduisant la faille y a été backporté le 15 avril). Debian Sid propose le noyau 2.6.30.

J'ai testé l'exploit, mais il ne fonctionne pas sur ma Debian, car il a besoin de Pulse Audio (qui n'est pas installé chez moi). Il semble que l'exploit utilise 3 failles différentes :
* Faille noyau (tun)
* Bug (faille) Pulse Audio
* Bug dans la fonction personality() permettant de contourner la protection "mmap_min_addr" (adresse minimale qui peut être mappée). Par défaut, on n'a pas le droit de mapper une zone mémoire à partir de l'adresse NULL.

Pff, il est long ton exemple ! En Python 3.1, ton exemple est deux fois plus court (4 lignes contre 8 lignes) :
from urllib.request import urlopen
url = 'http://download.savannah.gnu.org/releases-noredirect/tsp/dte(...)
with urlopen(url) as dlSavannah, open("what_is_dtest.pdf","wb") as f:
...f.write(dlSavannah.read())Avec le temps, les programmes Python deviennent de plus en plus court :-) Enfin, de plus en plus haut niveau (urllib est un niveau au dessus d'httplib).

En python, il faut tout réapprendre, en particulier, les messages d'erreurs que je trouve d'une confusion extrême.

De quels messages parles-tu ? Si tu parles des exceptions : entre une traceback qui indique exactement où tu es (nom du fichier + numéro de ligne + ligne de code pour chaque fonction de la pile) et "Segmentation fault", j'ai fait mon choix :-)

... pour m'apercevoir qu'entre python 2.3 et 2.5 la syntaxe d'un truc avais changé

Ça m'étonne, l'API standard est quand même hyper stable. Si tu parles de bibliothèques tierces : bah là ça dépend de la bonne volonté de ses mainteneurs. Mais ce problème n'est pas lié au langage effectivement :-)

il faut re-apprendre toute l'API: A chaque ligne, je suis obligé d'aller voir la doc: Ouvrir un fichier, vérifier les permissions, récupérer un signal....

Je trouve que l'API Python est très proche de l'API C (stdlib.h, stdio.h, signal.h, etc.). Au début, il faut juste trouver quel module contient telle ou telle fonction. Exemples C => Python :
* open(), close() => os.open(), os.close()
* fopen(), fclose() => f=open(); f.close()
* sigaction(num, func, &oldfunc) => oldfunc = signal.signal(num, func)
* access(path, mode) => os.access(path, mode)

Et puis, la doc Python est plus agréable à lire que les manpages C je trouve. http://docs.python.org/library/

... ils parlent bien des pilotes et semblent suggérer que les pilotes Windows peuvent être réutilisés tel quel.

...
2) ils mentent, ils ont pompé du code libre ...

As-tu lu la dépêche jusqu'au bout ? « Il semble d'ailleurs que Tmax Window ait réutilisé du code de ReactOS, qui est distribué sous licence GPL, pour le support des pilotes Windows. »

Cette info provient de l'article Tmax Window Uncovered, section "Account of Actual Developer", qui lui même cite un article de blog en coréen.

Je ne vois pas en quoi c'est un mensonge de réutiliser un logiciel libre. Par contre, s'ils comptent en faire un logiciel propriétaire, réutiliser des bouts de code GPL va poser problème. Sinon, ils ont jusqu'à Octobre (allez, Novembre...) pour virer le code GPL.

- toujours faire auditer le code par des personnes extérieures

Il faut des personnes compétentes, en particulier pour ce bug : des personnes connaissant (très) bien les générateurs de nombres aléatoires... ce qui est très rare.

- passer tous les tests des compilateurs (et équivalent : valgrind...) sans aucun warning

AHEM. La faille a été introduite à cause d'un faux positif Valgrind...

- avoir un code très propre et bien documenté aux passages critiques
- avoir une API simple et claire

L'API OpenSSL est très claire (pas juste l'API publique, l'API interne également).

- avoir une batterie de test la plus large possible

Le problème dans le cas de Debian OpenSSL est que le générateur était parfaitement aléatoire, il passe tous les tests, même les plus complets. Le problème était celui de la graine, et il semble qu'aucun outil ne teste la qualité de la graîne : s'assurer que N générateurs génèrent N suites différentes. Même s'il existe un tel outil, il faut que l'outil pense à exécuter chaque générateur dans un processus différent... Or pour des raisons pratiques, on va préférer tout faire dans le même processus.

Le bug Debian OpenSSL est un cas très particulier et il n'existait pas de test pour détecter le bug. Maintenant, il faut espérer que l'histoire ne se répête pas.

PS : Hasard contient un outil pour tester que N générateurs génèrent N suites différentes. Je parlais d'un test utilisant fork(). Et bien il semble que mon outil ait trouvé un (nouveau) bug, différent. fork() est encore un autre cas :-/

J'ai recompilé OpenSSL après avoir réintroduit le bug. Les tests d'Hasard 0.9.6 sont finalement insuffisant. Le test "init" réutilise le même processus, et on obtient donc des suites différentes. Par contre, j'ai modifié les tests fork_xxx pour forker N fois (1, 2^15 ou 2^20, selon les options --slow et --very-slow). Avec N=2^15, le bug OpenSSL est détecté (presque à la fin, vers ~32.100 essais).

Vu que j'ai du écrire un test spécifique à ce bug, je me demande si demain on ne pourrait pas trouver un autre type de bug demandant également un test précis :-/

Hasard intègre de nombreux tests pour vérifier que N générateurs différents génèrent N suites différentes. En particulier, le programme python/test_hasard.py comporte les tests :
* init : crée 10 (par défaut), 2^10 (option --slow) ou 2^20 (option --very-slow) générateurs différents et vérifie que les nombres générés sont différents
* reseed : appelle la fonction reseed(), qui regénère la graîne d'un générateur, 10, 2^10 ou 2^20 fois en s'assurant que le générateur génère des suites différentes
* fork_* (~17 tests) : vérifie qu'après un fork les deux générateurs (procesus parent et processus fils) génèrent des suites différentes

J'avoue ne pas avoir testé la version OpenSSL mais je compte le faire. Je suppose que la suite "init" devrait trouver le bug très rapidement.

Il y a une longue liste noire pour ces tests, car les générateurs faibles (dont l'état interne ou la graine font 32 bits ou moins) échouent rapidement. Le générateur libc_rand (fonction rand() de la libc) échoue par exemple après moins de 100.000 tests. Je viens de lancer le test "init" et j'ai obtenu une collision après 55094 essais. Ceci signifit qu'un attaquant a un espèce de recherche très restreint. Les générateurs utilisés dans Hasard utilisent un état interne et une graine d'au moins 128 bits. Consultez l'article suivant pour la théorie sur le risque de collision :
http://fr.wikipedia.org/wiki/Paradoxe_des_anniversaires