Victor STINNER a écrit 1639 commentaires

Pendant de longues années, mon site perso était hébergé sur en « mutualisé » chez OVH. Je n'avais qu'un accès FTP, protocole vieillot, qui passe mal les parefeux, lents, et surtout NON CHIFFRÉ ! Je viens de découvrir l'hébergeur AlwaysData qui propose un accès SSH, ce qui permet d'utiliser scp pour envoyer des fichiers, et offre donc un shell pour modifier directement les fichiers sur le serveur.

SSH est plus rapide et surtout beaucoup plus sûr (chiffré) que l'horrible FTP.

GCC 4.4.1 et 4.5 (snapshot du 27 août dernier) sont installables via MacPorts.

Fink permet d'installer GCC 4.4.1.

Je doute fortement qu'un client Mac lambda (celui qui a un iPod, iPhone et écoute en U2 en boucle) compile ses propres logiciels. On parle bien de développeurs là. Et il existe des développeurs capables d'installer GCC ;-)

Note : GCC 4.4.1 est la dernière version stable de GCC.

Hum, petit rappel : linuxfr est un site collaboratif. Comme tu sembles bien renseigné, n'hésite pas à proposer une dépêche pour les prochaines versions.

Il y a eu deux versions de cette dépêche. J'ai refusé la première parce qu'elle était trop maigre. Je trouve que le deuxième version était encore trop maigre, mais elle a quand même été approuvée :-) C'est génial quand on a plusieurs dépêches / journaux qu'on peut recouper pour en faire une dépêche plus complète. Mais quand on reçoit juste une dépêche maigre, on hésite entre ne rien publier (dommage) ou publier quand même.

Pour proposer une dépêche :
http://linuxfr.org/submit.html

PS : En plus, on peut gagner des livres, abonnements à des magazines, etc. J'ai reçu mon livre Ruby, yahoo !

L'auteur de grsecurity (suites de patchs pour le noyau visant à en reforcer la sécurité), Brad Spengler, a pris un malin plaisir à démontrer que SELinux (le concurrent de grsecurity) était faillible (contient une faille qui permettait de contourner les protections). Il a fait de même pour les autres systèmes de sécurité (LSM et audit en général). Voir les articles suivants pour les détails :
http://linuxfr.org/2009/07/18/25744.html
http://linuxfr.org/2009/07/24/25761.html
http://linuxfr.org/~patrick_g/28661.html

C'est grâce à au travail de Brad que la sécurité de SELinux a été renforcée dans Linux 2.6.31.

Au sujet de mmap_min_addr, je pense que cet article explique bien l'histoire.

Perso j'ai passé des heures à regarder defrag.exe. Mais je préférai son ancêtre sous MS-Dos, l'outil Norton dont j'ai oublié le nom, qui utilisait des couleurs plus jolies et il n'était pas nécessaire de scroller pour voir les animations :-) En plus, y'avait la douce musique du disque dur qui grattait. Ah quand je vais raconter ça à mes enfants qui auront des disques SSD avec défragmentation en ligne...

MiB : yep, d'extraterrestres, de flashouilleurs et de Will Smith.

Nan je déconne, MiB c'est Mailinblack !

Rah mince, la syntaxe (a href=...) ne fonctionne pas dans un commentaire ?

* The Big Kernel Lock lives on: http://lwn.net/Articles/86859/
* tty: BKL pushdown: http://lwn.net/Articles/268721/
* The big kernel lock strikes again: http://lwn.net/Articles/281938/
* "kill the Big Kernel Lock (BKL)" tree: http://lwn.net/Articles/282319/
* Removing the Big Kernel Lock: http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock
* Kill BKL Vol. 2: http://lwn.net/Articles/283066/

Raah, je lis sans arrêt "Kill Bill".

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...