URL: https://linuxfr.org/news/sortie-officielle-du-noyau-linux-3-4 Title: Sortie officielle du noyau Linux 3.4 Authors: patrick_g baud123, Davy Defaud, detail_pratique, Benoît, laurent wandrebeck, Benoît Sibaud, claudex, Damien Szczyt, khalahan, Akiel et _PhiX_ Date: 2012年04月09日T12:02:50+02:00 License: CC By-SA Tags: kernel, grsecurity, selinux, smack, lwn, peter_de_schrijver et sortie_version Score: 118 La sortie de la version stable 3.4 du noyau Linux [vient d'être annoncée par Linus Torvalds](https://lkml.org/lkml/2012/5/20/126). Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site [kernel.org](http://kernel.org/). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. PS. : Merci à toutes les personnes qui ont aidé à traduire les courriels de RC quand cette dépêche était dans l'espace de rédaction: laurent wandrebeck, detail\_pratique, khalahan, \_PhiX_, Damien Szczyt, Akiel et Benoît. ---- [LWN 1: Les nouveautés du noyau 3.4](https://lwn.net/Articles/487417/) [LWN 2: Les nouveautés du noyau 3.4](https://lwn.net/Articles/488131/) [LWN 3: Les nouveautés du noyau 3.4](https://lwn.net/Articles/489665/) [Les nouveautés sur le site h-online](http://www.h-online.com/open/features/What-s-new-in-Linux-3-4-1575313.html) ---- #La phase de test ## RC-1 La version [RC-1](http://article.gmane.org/gmane.linux.kernel/1275991) a été annoncée par Linus le 31 mars 2012 :> _Ok, cela fait deux semaines et la période de merge est terminée. Linux 3.4-rc1 a été envoyé vers les serveurs git, et l'archive tar ainsi que les patches sont en cours d'envoi alors que je tape ceci (cela sera probablement terminé le temps que je finisse)._> _Et oui, si vous avez compté, cela ne fait que 13 jours. Et si certains attendaient le dernier jour pour envoyer leur demande de merge, je suis persuadé qu'ils seront vraiment ravis d'attendre deux mois supplémentaires jusqu'à la prochaine fenêtre d'intégration. Yay !_> > _Cela dit, il y a encore quatre demandes de merge dans ma boîte mail qui sont en attente et que je vais (probablement) inclure, mais je voulais d'abord obtenir confirmation *d'autres* mainteneurs. Elles ont donc été envoyées dans les temps, j'ai juste décidé de faire le choix de leur intégration un peu plus tard._> _Les quatre requêtes restantes (et les gens dont je veux des commentaires) sont :_> > _- HSI (High Speed Synchronous Serial Interface). Je prévois de l'inclure dans le 3.4, c'est dans ma liste, mais je voulais que ça se sache au cas où quelqu'un aurait des problèmes avec cette dernière. Ping ?_> _- pohmelfs. Le vieux pohmelfs a été supprimé de staging ; il y en a un tout nouveau en attente sur le banc de touche. Al était un peu mécontent de certains aspects, Evgeniy en a corrigé certains, et la discussion s'est tarie. À nouveau, il y a des chances que je l'incorpore, mais je voulais davantage de commentaires à ce propos._> _- La prise en charge préliminaire de drm dma-buf. Dave Airlie m'a envoyé la demande d'incorporation mais n'a pas beaucoup insisté, c'est dans ma catégorie « ok, je peux encore l'inclure pour 3.4 si les gens des pilotes DRM me disent que ça leur facilitera la vie. » C'est donc dans le flou — je n'ai rien contre, mais je ne l'inclurai pas à moins que quelques personnes me disent « oui, s'il te plaît. »_> _- Le framework DMA-mapping. Ce code a dorénavant quelques confirmations supplémentaires, et se trouve essentiellement dans la même situation que HSI : je l'incorporerai probablement, mais je voulais vraiment avoir l'avis des personnes concernées._> > _Et c'est tout. Il y a donc quatre demandes d'inclusion en attente, mais à part ça, c'est terminé (à moins que vous ne puissiez démontrer m'avoir envoyé un mail, mais qu'à cause d'une erreur cosmique — impliquant probablement mon incompétence — je l'ai manqué. Hé, ça arrive)._> _Quoi qu'il en soit, assez parlé de « ce qui reste en attente ». Si vous voulez savoir ce qui a été incorporé, une approche assez lisible est la suivante :_> > ```bash> git log --merges --author=Torvalds v3.3..> ```> > _Parce que j'ai vraiment essayé de faire des messages compréhensibles, avec des informations venant des sous-mainteneurs. Et beaucoup d'entre vous m'en ont envoyé, merci._> _Un point important à signaler est que le nettoyage des fichiers d'en-têtes était un truc à faire, mais j'espère qu'on n'aura plus à le refaire. En tout cas, pas avant une version ou deux. Ce nettoyage a provoqué beaucoup de conflits de merge et quelques autres ennuis et, bien que je sois OK pour les résoudre, c'était suffisamment pénible pour que je ne veuille pas recommencer de sitôt. Je sais que des sous-mainteneurs ont eux aussi été embêtés et s'en sont plaint auprès de moi._> _Cela dit, je pense que c'était utile. Le découpage de `asm/system.h` (et à plus petite échelle les nettoyages de `bug.h`) a peut-être été douloureux, mais les choses sont vraiment plus propres. Je devine donc que nous *ferons* à nouveau ce genre de chose dans le futur, mais je veux juste oublier à quel point c'est pénible d'ici à la prochaine fois. Ok ?_> > _Dans tous les cas, merci de tester et rapporter toutes régressions._ ## RC-2 La [seconde version candidate](http://article.gmane.org/gmane.linux.kernel/1278709) du noyau est sortie le 7 avril 2012 :> _Une autre semaine, une autre -rc. Cela m'a *semblé* plutôt calme, mais à en croire les chiffres, c'est une -rc2 assez typique, peut-être même avec un peu plus de modifications qu'à l'accoutumée._> > _Cela dit, il n'a pas l'air d'y avoir beaucoup de choses effrayantes. Une bonne partie des changements sont des correctifs (que j'espère quasi-finaux) pour les modifications des fichiers d'en-têtes, ainsi que les trois demandes d'inclusion mentionnées dans l'annonce de la -rc1 : HSI (High Speed Synchronous Serial Interface, les bases de dma-buf, et ce qui concerne DMA mapping. Ces trois-là ont été soutenues par plusieurs personnes braillant un « vas-y, envoie ». Pohmelfs n'a pas été mergé, pour la simple raison que personne ne l'a demandé._> > _En dehors des correctifs sur les fichiers d'en-têtes et les 3 incorporations retardées, il n'y a que les correctifs habituels. Je serai plus strict en ce qui concerne les inclusions à partir de maintenant car il y a eu beaucoup de « bruit » et pas uniquement des corrections. J'en suis en partie responsable : une série de modifications d'Eric Paris visant à grandement améliorer l'usage de la pile dans le contexte SElinux._> _La plupart des changements concernent quelques architectures (arm, tile, powerpc, x86) et les pilotes (particulièrement le réseau, mais aussi regulator, drm et mmc), ainsi que quelques mises à jour sur la gestion de l'énergie._> > _J'espère que la -rc3 aura un résumé carrément plus court._ ## RC-3 C'est le 15 avril que la version [RC-3](http://article.gmane.org/gmane.linux.kernel/1282306) a été annoncée par Linus : > _Bon, ça fait donc huit jours depuis la -rc2, principalement parce que j'ai passé du temps à courir après deux bugs que je pouvais reproduire plutôt que de rendre cette version disponible hier. L'un était un oops dans la couche de gestion d'erreur scsi, et l'autre un plantage étrange sur x86-32. Bug introduit par mes soins. Oops._> > _Enfin bref, un jour de retard, mais nous sommes maintenant plus stables du fait de la correction de ces problèmes dans la -rc3. Les deux étaient suffisamment obscurs pour ne pas toucher grand monde, mais je déteste annoncer des versions candidates avec des problèmes que je peux reproduire personnellement._> > _Ceci dit, je ne pense pas qu'il y ait grand chose de bien excitant dedans. Il s'agit principalement de mises à jour de pilotes, avec une poignée de correctifs d'architecture et de réseau. Les statistiques de modifications sont assez barbantes, exception faite de la mise à jour du pilote mtip32xx et d'un changement trivial dans kyrofb (remplacement des_ unsigned long _par_ u32, _afin que ça fonctionne correctement en 64 bits) — cette RC se résume en gros par un bon nombre de simples remplacements._> > _Et des statistiques barbantes sont une bonne nouvelle. Cela signifie simplement « beaucoup de petits trucs ». Je l'admets, cela aurait été encore mieux si cela avait été « à peine quelques petits trucs », mais nous sommes *raisonnablement* tôt dans la séquence des versions candidates, je ne m'inquiète donc pas trop._ ## RC-4 La version [RC-4](http://article.gmane.org/gmane.linux.kernel/1285855) est disponible depuis le 21 avril : > _Tout semblait calme depuis un moment, mais ça a changé hier. Je pense que soit les gens envoient leurs requêtes juste avant que je ne rende disponible les -rc, soit c'est un problème de gens qui travaillent de lundi à vendredi et qui finissent la semaine en m'envoyant leurs requêtes._> _Peu importe le pourquoi, cela signifie que mon « oh, les choses se calment » de jeudi s'est transformé en « Uhhuh, en fait pas encore » le vendredi, quand plus de la moitié des modifications de cette -rc ont débarqué._> > _Ceci étant dit, même avec la pointe du vendredi, je pense que les choses ont tout de même été assez calmes. Nous avons eu quelques modifications annulées et un peu de nettoyage, mais la majorité sont des petits correctifs triviaux. Presque tous se situent dans les pilotes, avec quelques mises-à-jour du côté des systèmes de fichiers (la plupart étant des corrections de boutisme venant de Al) qui se sont glissées. Le traditionnel (sans renommage) fichier de différence est dominé par le déplacement du logo de démarrage m68k, mais nous utilisons tous les fichiers de différence de Git maintenant, n'est-ce pas ? Auquel cas, c'est 50% de pilotes (usb, mfd, xen, mmc, gpu, media...), 20% archi, 15% fs et une poignée de trucs ici et là._> > _Mais rien de tout cela n'a vraiment l'air effrayant. Il semble que la sortie de la 3.4 soit dans les clous, mais n'hésitez pas à brailler si vous repérez des régressions._> > _Je serai sans connexion pendant quelques jours (classe de plongée sous-marine, etc.), mais si le modèle « les gens m'envoient leurs trucs le vendredi » se vérifie, je parie que cela ne changera rien pour personne. D'autant que j'aurai mon portable et mon environnement de travail, donc si un truc surgit, tout se passera bien. Je ne suis simplement pas autant en ligne que d'habitude._ ## RC-5 Huit jours après la RC-4, Linus a annoncé sur la liste de diffusion la sortie de la version [RC-5](http://article.gmane.org/gmane.linux.kernel/1289428) :> _À nouvelle semaine, nouvelle -rc. Techniquement ça fait 8 jours — j'ai retardé la sortie d'une journée dans l'attente de quelques tests._> _Tout comme la -rc4, une bonne partie des modifications sont arrivées vendredi (et quelques autres hier). Et cela ne s'est pas calmé, au contraire. -rc5 a presque 50% de modifications en plus que n'en avait -rc4. Ce n'est pas bon._> > _Ceci étant dit, je ne pense pas qu'il y ait quoi que ce soit de très effrayant là-dedans. C'est ennuyeux, certes (je hais vraiment les vilains problèmes d'ABI d'autofs avec lesquels je me suis battu ces derniers jours, par exemple), et j'aurais préféré que les choses fussent plus calmes, mais la plupart des changements sont assez petits et triviaux. C'est réparti de manière assez équitable : 50% de pilotes, 20% d'architecture, 15% de systèmes de fichiers (principalement btrfs et nfs), 5% de réseau, ainsi que du bruit aléatoire._ ## RC-6 La grande nouvelle de la journée du 6 mai 2012 a bien évidemment été l'annonce de la version [RC-6](http://article.gmane.org/gmane.linux.kernel/1292477) par Linus :> _Une nouvelle semaine, une nouvelle -rc — et je pense que nous sommes proches de la 3.4 finale. Merci donc de tester._> > _Il y a toujours plus de modifications que je ne le voudrais — et j'apprécierais que les choses se calment davantage encore, mais globalement les changements restent petits et simples._> _Environ la moitié des modifications sont dans les pilotes (et la partie réseau représente presque la moitié de ça), le reste provenant principalement de arch (PowerPC et ARM), système de fichiers (Btrfs et NFS), ainsi que du réseau (hors pilotes)._> _Mais tous les changements semblent vraiment triviaux, donc, au final, je le sens plutôt bien._> > _En avant pour les tests._ ## RC-7 Enfin [la dernière version candidate](http://article.gmane.org/gmane.linux.kernel/1296191) a été annoncé 12 mai 2012 :> _C'est quasi certainement la dernière -rc de cette série : les choses se sont vraiment calmées, et j'ai même envisagé de rendre disponible le 3.4 en cette fin de semaine, pour finalement conclure qu'une semaine de plus ne pouvait pas faire de mal._> > _Le résumé des modifications donne une bonne vision d'ensemble : il s'agit principalement de petites corrections ici et là pour des petits problèmes très précis. La plus grosse modification (et celle qui touchera probablement le plus de gens) est le changement i2c de Nouveau — il s'agit de la suppression de la dernière modification. Les routines i2c spécifiques ayant leurs propres problèmes et les routines génériques_ i2c-algo-bit _ayant été corrigées, Nouveau utilise maintenant les génériques._> _Le reste est principalement constitué de petites modifications dans diverses zones : pilotes (réseau, DRM, SCSI, son et md), mises à jour d'archi (ARM, PowerPC et x86) et divers autres endroits : cœur du réseau, un correctif de compatibilité, des choses comme ça. Rien d'effrayant._> > _Alors lancez‐vous et testez. Et ne m'envoyez aucune demande d'inclusion à moins qu'elle ne contienne *que* des correctifs pour de très vilains bogues. Je ne veux plus de ces stupides correctifs pour supprimer des warnings du compilateur, etc._ En plus de cette annonce sur la LKML, Linus a décidé, comme il le fait régulièrement, de poster [un petit texte sur son compte Google+](https://plus.google.com/109995262342451767357/posts/DwW1v7Tam8K), afin d’inciter les gens à tester cette dernière version candidate :> _Dernière -rc avant la sortie de 3.4 ! Dépêchez-vous avant épuisement des stocks !_> _Du fait de l'édition limitée de 3.4-rc7, et si vous voulez que votre maman soit fière de vous demain, vous feriez bien de vous dépêcher. Et si vous êtes une maman, montrez à vos enfants que vous êtes exceptionnelle, car vos machines n'utilisent que le plus récent et le meilleur._> _Parce que vous le valez bien._> > _Et si vous êtes un développeur, rendez-nous tous fiers en n'envoyant pas davantage de « correctifs des warnings du compilateur » ou autres modifications sans intérêt. Si vous m'envoyez une demande d'inclusion ou un patch destiné à la version finale de 3.4, il vaudrait mieux que cela concerne une regression majeure, un oops ou un correctif de sécurité._> _Compris ?_ #Les nouveautés ##Architecture x32 Aux côtés de ses cousines [x86](http://en.wikipedia.org/wiki/X86) et [x86-64](http://en.wikipedia.org/wiki/X86-64), la nouvelle architecture [x32](http://en.wikipedia.org/wiki/X32_ABI) fait son entrée dans le nouveau noyau Linux 3.4. On sait que l’architecture x86-64 est une modernisation profonde de la vénérable architecture x86. Les registres généraux passent de 32 bits à 64 bits et leur nombre double (16 registres au lieu de 8). La mémoire virtuelle n’est plus limitée à 4 Gio, le [bit NX](http://en.wikipedia.org/wiki/NX_bit) est implémenté. L’appel système `SYSCALL64` est très rapide et les instructions vectorielles disponibles sont au moins au niveau du [SSE2](http://en.wikipedia.org/wiki/SSE2). Toutes ces nouveautés, et le fait que sa prise en charge est désormais mature, font qu’il est de nos jours presque absurde d’utiliser une distribution en mode x86. Néanmoins, certains développeurs sont d’avis que l’architecture x86 garde quelques avantages. Par exemple, le fait de se limiter à 32 bits signifie que les pointeurs mémoires sont plus petits et induisent donc moins de pression sur les mémoires caches du processeur. C’est un point important, notamment pour l’embarqué, car le bon fonctionnement du cache est absolument crucial pour les performances du processeur. C’est quand même dommage de devoir choisir entre les indispensables 16 registres de x86-64 et l’empreinte mémoire réduite de x86. Serait‐il possible de créer une nouvelle variante qui ne retiendrait que les meilleurs aspects de ces deux architectures ? C’est précisément le but qu’avait en tête H. Peter Anvin quand il a posté sur la LKML les _patches_ proposant [l’architecture x32](http://article.gmane.org/gmane.linux.kernel/1184876). Les programmes compilés avec l’[ABI](http://fr.wikipedia.org/wiki/Application_binary_interface) x32 tourneront donc en profitant à plein des 16 registres 64 bits (comme sous x86-64) mais leurs pointeurs mémoires seront limités à 32 bits (comme sous x86). Bien entendu, ces programmes seront limités à un espace d’adressage de 32 bits (4 Gio), mais cela ne constitue pas vraiment un obstacle pour la plupart d’entre eux, en particulier dans l’embarqué. D’après les premiers tests, postés sur [le site spécialement dédié à x32](https://sites.google.com/site/x32abi/), les performances semblent encourageantes. Le test `181.mcf` du banc d’essais [SPEC](http://en.wikipedia.org/wiki/Standard_Performance_Evaluation_Corporation) CPU2000 a été utilisé car il est extrêmement dépendant de la mémoire, et il profite à fond d’une réduction de la pression sur le cache. Selon ce test, effectué sur un processeur Core i7, on obtient un gain de vitesse d’environ 32 % par rapport au mode x86-64. Comme prévu les performances sont très proches de celles de x86 (moins d’1 % d’écart). Le gain induit par les pointeurs mémoire 32 bits est donc bien visible. Si l’on regarde le test `186.crafty`, on devrait cette fois mettre en évidence le gain induit par l’utilisation des 16 registres 64 bits, puisque ce test est très dépendant du processeur. Là encore, la nouvelle architecture tient ses promesses, puisque l’architecture x32 n’est que 5 % plus lente que x86-64, mais qu’elle enregistre un gain de 29 % par rapport à x86. Les _patches_ de H. Peter Anvin ont été assez bien accueillis sur la liste de diffusion du noyau, mais Linus a quand même grogné sur un point précis. À l’origine, les valeurs relatives à la gestion du temps (`time_t`, `off_t` ou `timeval`) devaient être en 32 bits, ce qui impliquait que l’architecture x32 serait soumise au [bogue de l’an 2038](http://fr.wikipedia.org/wiki/Bug_de_l%27an_2038) (débordement du nombre de secondes entre 1970, l’origine du temps UNIX, et l’année 2038). Linus a été prompt [à envoyer](http://article.gmane.org/gmane.linux.kernel/1184914) un _Scud_ en soulignant que ce point était inacceptable :> _J’ai eu des journalistes qui m’ont posé la question et j’ai toujours répondu qu’en 2038 nous utiliserions tous des processeurs 64 bits. Je pense que c’est une réponse tout à fait raisonnable._> _Mais si ces processeurs 64 bits font en fait tourner un mode « rapide » 32 bits, alors cette réponse perd toute sa pertinence. À notre époque, c’est une erreur fondamentale que d’avoir `off_t` et `time_t` en 32 bits. Je détesterais d’avoir à introduire ça dans le noyau, ça me ferait gerber._ Ce point a été rapidement corrigé [en introduisant](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=45e877812926c69d643d6274347f79513a4ee934) une gestion du temps spécifique sur 64 bits pour l’architecture x32 (c’est la fonction `COMPAT_USE_64BIT_TIME`). [D’autres objections](http://article.gmane.org/gmane.linux.kernel/1184913) ont été soulevées, mais les révisions successives des _patches_ ont finalement convaincu Linus d’intégrer cette [ABI](http://fr.wikipedia.org/wiki/ABI "Définition Wikipédia") x32 dans la branche principale du noyau. Bien entendu, un tel changement mixant les caractéristiques de plusieurs architectures a des impacts bien au-delà du noyau Linux. La gestion de [la nouvelle architecture x32](https://lwn.net/Articles/456731/) doit être ajoutée dans GNU binutils, dans la Glibc et dans le compilateur GCC. Les distributions binaires doivent décider d'utiliser ce mode et proposer des exécutables x32 dans leur dépôts. C'est donc un travail de longue haleine qui commence et nous verrons dans les prochaines années si l'architecture x32 arrive à convaincre dans le monde de l'embarqué. ##dm-verity La couche du [_device‐mapper_](http://en.wikipedia.org/wiki/Device_mapper) présente dans le noyau est une interface virtuelle servant à faire communiquer entre eux des périphériques blocs. Cette gestion des volumes logiques permet, par exemple, de faire du RAID logiciel ou du chiffrement de disques entre divers périphériques en mode bloc. La couche _device-mapper_ du noyau 3.4 accueille un nouveau module nommée [_dm‐verity_](https://lwn.net/Articles/459420/), qui fera sans doute quelque peu polémique auprès des libristes les plus vigilants. Le but de _dm-verity_ est de vérifier l’intégrité des blocs de données d’un périphérique. Pour cela une empreinte est prise pour chaque bloc et chacune d’entre elles est mise en correspondance sur son bloc respectif via _dm-verity_. Comme le périphérique virtuel est monté en mode lecture seule, il n’est pas possible de changer l’empreinte, ce qui assure l’intégrité des données contre toute tentative de modification frauduleuse. Bien entendu, pour que la chaîne de confiance soit absolue, il faut que la machine puisse avoir une phase d’amorçage protégée. Cela se fait en utilisant _tboot_ ou TrustedGRUB, ou encore en démarrant à partir d’une clé USB ou d’un CD considérés comme sûrs. L’utilisateur de _dm-verity_ va alors fournir au système l’empreinte de la racine, et cette information est la clé qui permettra de vérifier, de proche en proche, que les blocs du périphérique (et donc les exécutables) n’ont pas été modifiés. C’est la technique classique de [l’arbre de hachage](http://fr.wikipedia.org/wiki/Arbre_de_Merkle) qui est ici utilisée (_Merkle tree_). [La documentation](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt;h=32e48797a14f80de6ebff7a441e489021bfce58a;hb=a4ffc152198efba2ed9e6eac0eb97f17bfebce85) indique que la vérification se fait via l’outil `veritysetup` avec la syntaxe suivante : `veritysetup -a vroot /dev/sda1 /dev/sda2 hash_de_la_racine` Théoriquement à ce stade le lecteur attentif des dépêches noyau LinuxFr devrait se demander _« Mais en quoi est‐ce différent du sous‐système EVM [qui avait été décrit](http://linuxfr.org/news/le-noyau-linux-3-2-est-disponible#toc_11) dans la dépêche Linux 3.2 ? »_. Excellente question cher lecteur attentif ! Eh bien, tout d’abord, EVM fonctionne obligatoirement avec une puce TPM ([_Trusted Platform Module_](http://fr.wikipedia.org/wiki/Trusted_Platform_Module)), alors que _dm-verity_ n’a pas cette dépendance. Il peut utiliser une puce TPM (via [TrustedGRUB](http://projects.sirrix.com/trac/trustedgrub) notamment), mais, comme nous l’avons vu plus haut, il peut aussi se contenter d’un amorçage à partir un périphérique externe qui aura été gardé en lieu sûr (clé USB ou CD). Ensuite, la vérification des empreintes se fait seulement à la demande, quand le noyau à besoin de réellement accéder aux blocs sous‐jacents (lors d’un accès disque). Cela évite une coûteuse phase de vérification de toutes les empreintes lors du démarrage, ce qui améliore donc les performances. Le développeur Mandeep Singh Baines [a indiqué](http://article.gmane.org/gmane.linux.kernel/1191710) que _dm-verity_ était déjà utilisé par Google dans son projet Chrome OS :> _dm-verity fait partie de l'infrastructure de boot sécurisée de Chrome OS. Le module est utilisé pour vérifier l'intégrité du système de fichiers root lors du démarrage. Cette partition root est montée via un mapping dm-verity afin de vérifier, de façon complètement transparente, que chaque bloc correspond au hash qui a été passé lors du boot._ Une présentation de _dm-verity_ a été effectuée lors du [sommet _Plumber 2011_](http://www.linuxplumbersconf.org/2011/) qui s’est déroulé à San Diego en août dernier. Dans [le fichier PDF de présentation](http://selinuxproject.org/~jmorris/lss2011_slides/LSS_11_Integrity_checked_block_devices.pdf), on apprend que la vitesse de vérification a été un facteur crucial lors du choix d’architecture de _dm-verity_. Certes, EVM est une solution plus complète, mais la nécessité de ne pas ralentir le démarrage d’une machine Chrome OS a conduit au développement de cette alternative. Avec _dm-verity_, il est ainsi possible d’amorcer en 1,2 seconde une partition _root_ de 891 Mio. Bien entendu, cette technique de vérification d’intégrité peut aussi être utilisée par des constructeurs peu scrupuleux qui voudraient bloquer l’accès des utilisateurs à leur machine. Il est particulièrement inquiétant de lire [le courriel](http://article.gmane.org/gmane.linux.kernel/1191818) envoyé sur la LKML par Wesley Miaw qui travaille pour [Netflix](http://fr.wikipedia.org/wiki/Netflix). Cette société américaine propose un service payant de diffusion vidéo. On comprend facilement qu’elle puisse chercher à bloquer l’enregistrement de ce flux vidéo sur les _smartphones_ et tous les autres périphériques basés sur Linux :> _Netflix voudrait que dm-verity soit incorporé dans le noyau Linux. Au cours de l'année écoulée, nous avons travaillé avec Google afin de porter dm-verity sur un certain nombre de périphériques électroniques grand public tournant sous une version embarquée de Linux._> _La demande pour cette fonction a été importante et nous voyons pas mal de bénéfices à ce que dm-vérity fasse partie du noyau officiel._ Netflix a une politique de certification officielle des plates‐formes avant que l’utilisateur ne puisse accéder au flux vidéo (voir [cet exemple](http://www.pcmag.com/article2/0,2817,2388090,00.asp) avec les _smartphones_ OMAP 4). On peut craindre que _dm-verity_ ne soit utilisé pour bloquer toute tentative de changement des binaires, et que l’empreinte racine ne reste entre les mains du constructeur. Ce ne serait pas la première fois qu’une technologie potentiellement utile serait ainsi détournée pour asservir les utilisateurs. Comme le résume Jonathan Corbet sur [l’article de LWN dédié à ce sujet](https://lwn.net/Articles/459420/) :> _Certains vendeurs vont, sans aucun doute, choisir d'inclure des outils comme dm-verity sans donner aux utilisateurs la possibilité de le désactiver. Ce n'est pas une bonne chose, mais ce n'est pas non plus quelque chose de nouveau._ ##Nouveautés pour l'architecture ARM L'architecture ARM a le vent en poupe en ce moment et le noyau Linux 3.4 accueille de nombreuses nouveautés qui améliorent sa prise en charge et ajoutent des fonctionnalités. La première de ces nouveautés est l['unification de la gestion des horloges](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b2476490ef11134b65544d8f062cff96c53e941b) dans un nouveau sous-système dédié nommé _« Common CLK »_. C'est un travail de longue haleine qui a été entrepris par Mike Turquette, Jeremy Kerr et Ben Herrenschmidt puisque la première version a été proposée sur la LKML [il y a plus d'un an](https://lkml.org/lkml/2011/5/20/81). Auparavant le noyau Linux gérait de façon complètement séparée ce code de gestion des horloges matérielles. Chaque implémentation vivait dans des répertoires dédiés aux diverses architectures. Plutôt que cette solution inefficace d'un code spécifique pour chaque plateforme, le nouveau sous-système propose [une gestion matérielle unifiée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69fe8a8e92ae6877167f222838bd0c92b35c7d72) :> _The common clk framework is an interface to control the clock nodes available on various devices today. This may come in the form of clock gating, rate adjustment, muxing or other operations. The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations._ [La documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=69fe8a8e92ae6877167f222838bd0c92b35c7d72) indique que l'option de configuration `COMMON_CLK` doit être choisie lors de la compilation et que l'interface est divisée en deux parties bien distinctes. La première s'appuie sur le code commun (un [struct](http://en.wikipedia.org/wiki/Struct_%28C_programming_language%29) clk unique ainsi qu'une API unifiée dans `include/linux/clk.h`) tandis que la seconde regroupe les [callbacks](http://fr.wikipedia.org/wiki/Fonction_de_rappel) spécifiques qui s'enregistrent avec `clk_ops`. Maintenant que ce sous-système commun unifié est disponible on va sans doute assister à la conversion progressive des pilotes dans les prochaines versions du noyau. Ce travail n'est pas vraiment spécifique à l'architecture ARM mais, étant donné la diversité qui existe sur cette architecture, c'est pour elle que ses effets bénéfiques vont se faire sentir avec le plus de force. Alors qu'avant il était impossible de compiler une image noyau identique pour deux plateformes ARM ayant des struct clk différentes, il devient maintenant envisageable, à moyen terme, d'avoir [une image multi-plateforme unique pour ARM](https://lwn.net/Articles/496400/). Moins de duplication de code et, [comme l'écrit Mike Turquette](http://article.gmane.org/gmane.linux.kernel/1218622), le but est bien d'avoir « The One Image to Rule Them All » ! Outre cette infrastucture _« Common CLK »_ le noyau 3.4 accueille également les patchs de [DMA-mapping](https://lwn.net/Articles/467509/) qui ont été écrits par Marek Szyprowski. Le [DMA](http://fr.wikipedia.org/wiki/Acc%C3%A8s_direct_%C3%A0_la_m%C3%A9moire) (**D**irect **M**emory **A**ccess) c'est la possibilité d'envoyer les données d'un périphérique directement dans la mémoire RAM, sans intervention du processeur. Bien entendu, cette technique doit tenir compte des particularités de l'architecture matérielle sous-jacente et une API unifiée est disponible dans le noyau Linux. Le problème, c'est que les développeurs ARM n'utilisaient pas vraiment ce code commun et qu'une certaine « balkanisation » était observée dans l'arbre des sources. Marek a mis fin à cette anarchie et [ses patchs](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=58bca4a8fa90fcf9069379653b396b2cec642f7f) simplifient la gestion des particularités de l'architecture ARM. Encore une nouveauté ARM intégrée dans ce noyau 3.4, la fonction « jump label » est maintenant utilisable pour les machines ARM et Thumb-2. Comme indiqué dans [la dépêche du noyau 2.6.37](https://linuxfr.org/news/sortie-de-la-version-2637-du-noyau-linux#long6) cette fonction « jump label » (d'ailleurs renommée depuis en « [static keys](https://lwn.net/Articles/487426/) ») permet de réduire drastiquement le coût des points de traçage, mais elle nécessite d'écrire un code assembleur adapté à chaque architecture. C'est Vincent Rabin qui [s'est chargé de ce travail](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=09f05d8529ff4aa92311c1a55ce35ac98cb59b8c) pour ARM et cette fonction est utilisable avec l'option de configuration `HAVE_ARCH_JUMP_LABEL`. Le JIT ([compilateur à la volée](http://fr.wikipedia.org/wiki/Compilation_%C3%A0_la_vol%C3%A9e)) qui permet [d'accélérer le traitement des paquets réseau](http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_14) du filtre Berkeley Packet Filter, est [maintenant disponible](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ddecdfcea0ae891f782ae853771c867ab51024c2) sur architecture ARM. Cette fonction est utilisable via l'option `HAVE_BPF_JIT` et elle s'active avec un petit `echo 1> /proc/sys/net/core/bpf_jit_enable`. Enfin, du côté de la prise en charge du matériel, le développeur Peter De Schrijver a écrit [un patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=86e51a2ee471062184d2f74b46c45d344a2b9b38) ajoutant la gestion de la plateforme [Tegra3](http://fr.wikipedia.org/wiki/Tegra#Tegra_3) avec son « processeur compagnon ». On voit ainsi que NVidia, société pour laquelle travaille Peter, souhaite améliorer la prise en charge native de ses SoCs dans la branche principale. Le noyau 3.4 apporte également la prise en charge de la plateforme [Exynos5](http://en.wikipedia.org/wiki/Exynos) de Samsung. C'est le tout premier System on Chip à utiliser le nouveau coeur [Cortex-A15](http://en.wikipedia.org/wiki/ARM_Cortex-A15_MPCore). ##YAMA Après plus d'un an et demi d'hésitations et de débats, le [module de sécurité YAMA](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d514487faf188938a4ee4fb3464eeecfbdcf8eb) a finalement été intégré dans le noyau Linux 3.4. Cet ajout est une bonne occasion pour évoquer les controverses qui persistent entre les développeurs au sujet de la sécurité de Linux. Il a toujours été difficile de trouver un équilibre entre la sécurité à tout prix, au détriment même de la propreté du code et de sa maintenabilité, ou bien une approche plus pragmatique et mesurée. Tout commence le 16 juin 2010 avec [un mail de Kees Cook](http://article.gmane.org/gmane.linux.documentation/1638) sur la liste de diffusion du noyau. Kees, qui était alors [responsable sécurité](http://outflux.net/prof/resume.php) chez Canonical, soutient que l'appel système [ptrace](http://pwet.fr/man/linux/appels_systemes/ptrace) est potentiellement dangereux et il propose un patch pour bloquer cette faille. La commande `ptrace` est souvent utilisée pour les phases de déboguage car elle permet à un processus d'éditer l'espace mémoire d'un autre processus. [D'après Kees Cook](http://article.gmane.org/gmane.linux.documentation/1638), un attaquant peut exploiter cette capacité afin d'élargir la surface d'attaque d'une compromission initiale : > _Une faiblesse particulièrement troublante de l'interface des processus sous Linux est qu'un simple utilisateur peut examiner le statut et la mémoire de chacun de ses processus._> _Par exemple, si une application (par exemple Pidgin) est compromise, alors il est possible pour un attaquant de s'attacher à un autre processus (par exemple Firefox, une session SSH, un agent GPG, etc.) afin d'extraire des informations sensibles additionnelles et continuer son attaque._ Le patch de Kees est simple puisqu'il se contente d'ajouter un `sysctl` (une [interface de paramétrage](http://fr.wikipedia.org/wiki/Sysctl)) contrôlant le comportement de `ptrace`. Ce nouveau paramètre, nommé `ptrace_scope`, peut prendre les valeurs « 0 » ou « 1 ». Par défaut, c'est « 0 » qui est utilisé (mode « classic ») et cela signifie que le comportement de `ptrace` ne change pas par rapport à la situation actuelle. En revanche, quand `ptrace_scope` est à « 1 » (mode « restricted »), alors un processus ne peut lancer `ptrace` que sur ses processus fils et toute tentative d'examiner la mémoire des autres processus échouera. On notera que le travail de Kees Cook s'inspire largement d'[une fonction qui existe déjà dans Grsecurity](http://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Deter_ptrace-based_process_snooping). L'option `CONFIG_GRKERNSEC_HARDEN_PTRACE` interdit en effet de lancer `ptrace` sur des processus arbitraires et limite le choix aux processus fils. Les réactions sur la LKML n'ont pas été d'un enthousiasme délirant et Alan Cox a été prompt à [manifester son opposition](http://article.gmane.org/gmane.linux.documentation/1639) au patch de Kees :> _Les autres distributions font ça de façon rationnelle en utilisant des choses comme SELinux. Cela permet de décrire les relations de façon complète et on contrôle tous les chemins d'accès, pas seulement ptrace, pouvant être utilisés par un attaquant._> _Même si tu t'en tapes d'utiliser les mêmes fonctions de sécurité que le reste du monde, de toute façon ton patch, et les autres trucs que tu as postés, tout ça doit aller dans un module de sécurité à part._> _Donc NAK. Si tu veux réutiliser des morceaux de grsecurity alors, s'il te plaît, écris un module noyau grsecurity qui se basera sur les hooks qui existent. Arrête de pourrir le cœur du code. C'est aussi simple que ça. L'infrastructure existe alors utilise-là._ James Morris, le responsable de SELinux, a même souligné que son module de sécurité avait déjà un booléen, nommé `allow_ptrace`, et permettant de contrôler le comportement de `ptrace`. Pourquoi alors réinventer la roue ? Le problème c'est que tout le monde ne veut pas utiliser SELinux. Les réfractaires sont nombreux et ils sont d'avis que SELinux est trop compliqué à utiliser. Même un hacker aussi réputé que Ted Ts'o avoue être découragé :> _Il y a un bon nombre de gens qui n'utiliseront jamais SELinux. Tous les deux ou trois ans, je jette un nouveau coup d'œil sur SELinux, ma tête explose devant la complexité (non nécessaire ÀMHA) et je prends une nouvelle fois le large._ La situation paraît donc complètement bloquée entre les zélotes d'un module SELinux ultra-puissant mais complexe et les partisans d'une solution plus simple, même si elle est moins complète. La solution régulièrement évoquée pour faire face à ce problème est « l'empilage des modules de sécurité » (_LSM stacking_). Avec cette solution, il devient possible d'avoir un « gros » module qui couvre le cas général (comme SELinux) et un ou plusieurs autres modules qui ne s'occupent que de fonctions bien précises sur lesquelles l'utilisateur veut avoir le contrôle. Actuellement, le code LSM du noyau ne permet le chargement que d'un seul module de sécurité, à l'exclusion de tous les autres. Avec le _LSM stacking_ cette limitation disparaîtrait et le noyau Linux offrirait plus de souplesse à ses utilisateurs. En attendant que les développeurs se mettent d'accord sur une solution technique propre pour implémenter cet empilage des modules, Kees Cook a donc réécrit son patch afin d'isoler le code à l'intérieur d'un nouveau module de sécurité [nommé YAMA](http://article.gmane.org/gmane.linux.kernel.lsm/11225). En plus de la restriction d'utilisation de `ptrace`, on trouve dans le module [des protections supplémentaires](http://article.gmane.org/gmane.linux.kernel.lsm/11225) sur l'utilisation des liens symboliques ([symlink](http://fr.wikipedia.org/wiki/Lien_symbolique)) et des liens matériels ([hardlink](http://fr.wikipedia.org/wiki/Lien_mat%C3%A9riel)). L'intégration du module YAMA a été proposée sur le LKML le 21 juin 2010... mais, dès le 2 août, [Kees a posté un message](http://article.gmane.org/gmane.linux.kernel/1017184) indiquant qu'il était obligé de retirer le module puisque Christoph Hellwig avait posé un veto empêchant l'inclusion dans le noyau. [Les objections de Christoph](http://article.gmane.org/gmane.linux.kernel/1017392) se concentrent sur le fait que YAMA n'est pas un module de sécurité cohérent et qu'il n'est qu'une collection hétéroclite de divers patchs visant à bloquer des failles potentielles. À ce stade de la situation on ne peut que comprendre [la frustration de Kees](http://article.gmane.org/gmane.linux.kernel/1017536) :> _Je commence à être fatigué de devoir porter mes patchs d'un côté ou de l'autre entre les sous-systèmes ou les modules de sécurité. Vous m'avez demandé de tout mettre dans un module et maitenant vous me dites que je ne devrais pas faire ça._> _La situation est très simple. Soit vous me laissez mettre tout ça dans un module pour que les gens puisse choisir de l'activer. Soit vous m'aidez à améliorer les patchs, afin qu'ils intégrent directement les sous-systèmes._> _Comme la seconde solution a été refusée à plusieurs reprises, il m'a été suggéré d'opter pour la première, ce que j'ai fait. L'option de tout abandonner n'est pas envisageable._ La ~~_flame war_~~ discussion a donc été relancée et certains développeurs ont [tenté d’expliquer](http://article.gmane.org/gmane.linux.kernel.lsm/11574) à Kees ce qu’ils reprochaient à ses patchs :> _Tu n'évoques pas la solution que t'a suggérée Al : Il faut avant tout **réfléchir** au problème de façon approfondie au lieu de balancer des patchs qui ne s'occupent que d'un seul cas de figure._> _Ici on ne bloque qu'un seul type spécifique d'attaque sans créer un modèle conceptuel de la menace. C'est la grande distinction entre SELinux, Tomoyo, Smack et puis tes patchs à toi. Ces modules de sécurité forment un **modèle** de ce qui est important à protéger et de **comment** le protéger. Ils ne se contentent pas d'appliquer des règles arbitraires pour empêcher certaines attaques._>_Les gens s'inquiètent parce que ton module pourrait grossir en accumulant des tonnes de règles spécifiques qui créeraient une sécurité **apparente** sans vraiment procurer une sécurité **réelle**._ Kees Cook a [tenté de faire valoir son point de vue](http://article.gmane.org/gmane.linux.kernel/1018279) et a souligné la situation impossible dans laquelle il se trouvait confiné :> _Vous pouvez voir, comme moi, que la situation est un [catch 22](http://en.wikipedia.org/wiki/Catch-22_%28logic%29). « Nous n’avons pas besoin de la fonction d’empilage parce qu’il n’y a rien à empiler » et « nous n’avons pas besoin d’un micro‐module parce qu’il est impossible d’empiler les modules. »_ Le blocage étant total, il a été décidé d’attendre la prochaine conférence sur la sécurité du noyau, afin que la situation se décante et que les protagonistes puissent se parler directement. C’est donc en septembre 2011 que James Morris et les autres développeurs responsables de la sécurité se sont retrouvés. Dans le [programme](https://security.wiki.kernel.org/articles/l/i/n/LinuxSecuritySummit2011_Schedule_14a8.html), on peut voir que Kees Cook animait une discussion portant le titre suivant: _« LSM Architecture: modularity, stacking »_. Le [compte‐rendu](http://paulmoore.livejournal.com/6886.html) que Paul Moore a fait du _Linux Security Summit 2011_ indique que le sommet a bien joué son rôle et que l’avis des développeurs a changé au sujet du l’empilement et de la concurrence entre les modules. Cette évolution s’est matérialisée en mars 2012 quand James Morris a [officiellement accepté](https://lkml.org/lkml/2012/3/20/510) d’intégrer le module de sécurité YAMA dans sa branche destinée au noyau Linux 3.4. Le fait que ce code soit déjà en cours d’utilisation dans divers projets n’est sans doute pas étranger à cette inclusion :> _Le principal ajout est le nouveau module de sécurité YAMA, écrit par Kees Cook, et qui a été discuté l'année dernière au sommet sur la sécurité. Son but est de rassembler divers mécanismes de sécurité [DAC](http://fr.wikipedia.org/wiki/Contr%C3%B4le_d%27acc%C3%A8s_discr%C3%A9tionnaire "Définition Wikipédia") en un seul endroit. Cela marque également un changement de politique en ce qui concerne les modules LSM qui étaient auparavant tous des mécanismes complets de contrôle d'accès._> _Chromium OS utilise YAMA et je crois qu'il y a des plans pour Ubuntu._ Kees [a précisé](http://article.gmane.org/gmane.linux.kernel.lsm/13094) qu'en fait Ubuntu utilisait déjà YAMA depuis octobre 2011 et il a également fourni [un lien](http://codereview.chromium.org/6677065) vers l'inclusion de YAMA dans Chromium OS. Selon [la documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/security/Yama.txt;h=4f0b7896a21da15ebdac1c03f50e4be8ab1c0d43;hb=2d514487faf188938a4ee4fb3464eeecfbdcf8eb) présente dans les sources du noyau, on voit que seule la restriction de `ptrace` a été implémentée pour l"instant dans YAMA (_just ptrace restrictions for now_). Il est fort probable que les autres restrictions, celles qui concernent symlink et hardlink, intégreront plus tard le module. Un choix est donc désormais offert entre l'implémentation (souvent difficile) d'une politique de sécurité complète ou bien l'activation d'un module visant à regrouper divers patchs de renforcement de la sécurité. Nous verrons dans les prochains noyaux si la solution idéale que constituerait le « stacking LSM » parviendra à s'imposer. #En bref ##Maturation de btrfs Les distributions de Novell (SuSE Linux Enterprise) et d'Oracle (Unbreakable Enterprise Kernel) veulent absolument se différencier par rapport à Red Hat. C'est pour ça qu'elles ont choisi de supporter officiellement ([1](http://oss.oracle.com/el6/docs/RELEASE-NOTES-UEK2-en.html#btrfs) - [2](http://www.suse.com/company/press/2012/2/suse-linux-enterprise-11-service-pack-2-released.html)) le système de fichiers btrfs, même si il est encore considéré officiellement comme « experimental » dans la branche principale du noyau. Leurs patchs de fiabilisation arrivent maintenant dans le noyau 3.4 afin que tous les utilisateurs puissent en profiter. On trouve donc [un gros patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=79787eaab46121d4713ed03c8fc63b9ec3eaec76) de Jeff Mahoney, employé par SuSE, qui améliore la gestion des erreurs. Auparavant, c'était un simple et rustique appel à la macro `BUG_ON` qui était souvent utilisé (on enregistre l'erreur et on arrête le système). Maintenant la plupart des erreurs bénéficient d'un traitement spécifique et le crash du noyau est évité. Comme le résume Chris Mason :> _Nous avons mergé les patchs de gestion d'erreurs venant de SuSE. Ils sont déjà incorporés dans le noyau SLES et ils apportent à Btrfs la possibilité d'interrompre les transactions et de passer en mode lecture seule en cas d'erreur._ [Le message de Chris](http://article.gmane.org/gmane.comp.file-systems.btrfs/16527) récapitule les autres nouveautés concernant btrfs pour cette version du noyau. On peut voir notamment qu'un gros travail de performances a été effectué sur la gestion des métadonnées, sur la coopération avec le cache de page de Linux ou encore sur la réduction de l'empreinte CPU (voir par exemple [les patchs](http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git&a=search&h=HEAD&st=commit&s=Josef+Bacik) de Josef Bacik). En ce qui concerne les métadonnées du système de fichiers il est possible d'utiliser des blocs plus grands que 4 Ko. La limite est maintenant portée à 64 Ko et les tests montrent que l'optimum du gain de performances est atteint avec une taille de bloc égale à 32 Ko. Cette fonction s'active lors de la création du système de fichiers avec `mkfs.btrfs -l 32K`. Tout ce travail d'optimisation des performances porte ses fruits si on compare les graphes postés par Chris Mason entre les versions [3.3](https://plus.google.com/photos/105274031445877094012/albums/5725819775428547617/5725819775250665666) et [3.4](https://plus.google.com/photos/105274031445877094012/albums/5725820959365950049/5725821050029040946) du noyau. ##Simplifications dans ext4 En ce qui concerne le système de fichiers ext4, il n'y a pas de changements révolutionnaires, mais on trouve néanmoins plusieurs patchs de nettoyage intéressants. Ted Ts'o, qui peste depuis plusieurs mois devant le nombre d'options présentes dans ext4, a procédé à diverses simplifications du code. Par exemple, l'option de montage `journal=update`, qui a été introduite il y a dix ans pour faciliter les migrations depuis ext3, [a été retirée](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=43e625d84fa7daca0ad46f1dbc965b04fd204afe) du noyau 3.4. C'est la même chose pour l'option `resize` permettant de changer la taille lors du mount. Après tout, on utilise resize2fs alors pourquoi avoir cette option redondante ? [Un autre patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=26092bf52478d23f872c6531e9e3ea9bde2c66c1) utilise une table pour stocker les options de mount, ce qui, là encore, simplifie le code puisqu'on peut supprimer une centaine de lignes. Ted a également proposé de retirer les options `bsddf` et `minixdf` qui conduisent [l'outil df](http://fr.wikipedia.org/wiki/Df_%28Unix%29) à se comporter comme sous BSD ou MINIX... mais les cris d'orfraie sur la LKML l'ont finalement dissuadé. Pas découragé pour autant, il a fait remarquer qu'ext4 était le seul système de fichiers à proposer une option permettant l'activation ou la désactivation des [attributs étendus](http://fr.wikipedia.org/wiki/Attributs_%C3%A9tendus) lors du mount (options `noacl` et `nouser_xattr`). C'est fort peu utile, mais avant de supprimer ce code, il faut tout de même alerter la communauté. [Son patch](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f70486055ee351158bd6999f3965ad378b52c694) se contente donc pour l'instant de marquer ces options comme obsolètes (_deprecated_) et elles seront probablement retirées dès le prochain noyau. ##fadump pour PowerPC Dans cette version du noyau, l’architecture PowerPC [a gagné un mécanisme](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eb39c8803d0e3d98fe74825f99287f63d55e6460) de capture des données (_dump_) lors d’un éventuel crash de la machine. Ce nouveau système repose sur une coopération avec le micro‐logiciel, le _firmware_, ce qui explique son nom de _fadump_ (_firmware assisted dump_). Lors du démarrage initial, le noyau se sert du _firmware Power_ pour sélectionner des régions de la mémoire et les réserver au stockage des données pour analyse _post-mortem_. Au moment du crash, c’est le _firmware_ qui prend la main et qui sauve les données (ainsi que les registres système et les entrées dans la table des pages). Après ces opérations, l’administrateur peut redémarrer normalement. Le noyau va noter qu’il y a eu un crash (puisqu’une entrée `dump-kernel` aura été créée) et il va soigneusement éviter de toucher les zones mémoire réservées. Un programme en espace utilisateur pourra ensuite être utilisé pour lire `/proc/vmcore` et récupérer ces données pour analyse ultérieure. Ensuite, il ne faudra pas oublier de faire un petit `echo 1> /sys/kernel/fadump_release_mem` pour libérer la mémoire qui avait été réservée au stockage des données du crash. [La documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8e0aa6d436f303a37df7ec68758883ade077d123) de _fadump_ écrite par Mahesh Salgaonkar explique les deux avantages de cette procédure par rapport aux classiques _kexec_ et [_kdump_](http://lse.sourceforge.net/kdump/). Tout d’abord, le système est réinitialisé proprement avec une version fraîche du noyau, et ensuite, aussitôt que la copie du _dump_ est effectuée, la mémoire peut être réutilisée. Pas besoin d’un nouveau redémarrage. Pour profiter des avantages de _fadump_, il vous faudra un noyau compilé avec l’option de configuration `CONFIG_FA_DUMP`. ##UFS dans le noyau Le titre de ce paragraphe peut prêter à confusion, puisqu’il ne s’agit pas du système de fichiers bien connu [_Unix File System_](http://fr.wikipedia.org/wiki/Unix_File_System), mais bien de la norme [_Universal Flash Storage_](http://en.wikipedia.org/wiki/Universal_Flash_Storage). C’est l’organisation de standardisation [JEDEC](http://fr.wikipedia.org/wiki/JEDEC) qui s’est chargée de créer [cette nouvelle norme](http://www.jedec.org/standards-documents/focus/flash/universal-flash-storage-ufs) destinée au stockage sur mémoire Flash dans les appareils mobiles (_smartphones_, tablettes ou encore appareils photo). De nombreuses sociétés de l’embarqué (Nokia, Sony Ericsson, Texas Instruments, STMicroelectronics, Samsung, etc.) ont travaillé à l’élaboration de la norme, afin qu’elle offre une plus grande vitesse et une moindre consommation que le standard actuel des [cartes SD](http://fr.wikipedia.org/wiki/Carte_SD). L’architecture de communication utilisée est similaire à SCSI afin de profiter de la gestion des commandes multiples et d’offrir un modèle de programmation bien connu. [Les patchs de Santosh Yaraganavi](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7a3e97b0dc4bbac2ba7803564ab0057722689921) ajoutent au noyau le pilote UFS pour le _host controller_. Selon [la documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/scsi/ufs.txt;h=41a6164592aa1465317275255b40ddb4acf26b87;hb=7a3e97b0dc4bbac2ba7803564ab0057722689921), un peu de travail reste à faire en ce qui concerne la gestion de la consommation, mais on peut noter que les systèmes basés sur Linux sont les premiers à offrir la gestion de la norme _Universal Flash Storage_. ##Camellia et CRC32 L’optimisation des algorithmes de chiffrement va peut‐être devenir un paragraphe récurrent des dépêches noyau. En effet, après les _patches_ évoqués dans les dépêches du [3.2](http://linuxfr.org/news/le-noyau-linux-3-2-est-disponible#toc_17) et du [3.3](http://linuxfr.org/news/sortie-du-noyau-linux-3-3#toc_17), le développeur finlandais Jussi Kivilinna a frappé de nouveau. Cette fois, c’est l’algorithme [_Camellia_](http://fr.wikipedia.org/wiki/Camellia_%28algorithme%29) qui est concerné. Rappelons qu’il s’agit de l’algorithme de [chiffrement symétrique](http://fr.wikipedia.org/wiki/Chiffrement_sym%C3%A9trique) 128 bits arrivé en tête lors du concours [NESSIE](http://fr.wikipedia.org/wiki/Projet_NESSIE) de l’Union européenne. Comme pour ses _patches_ précédents Jussi a écrit [une implémentation en assembleur optimisé](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0b95ec56ae19f61ca664e83766a2180057f0e351) pour l’architecture x86\_64 (`camellia-x86_64-asm_64.S`). Le gain en performances est tout à fait notable par rapport au code C générique du noyau puisque, sur un processeur Core 2 T8100, on relève un écart s’échelonnant de 10 % à plus de 70 % (en [mode ECB](http://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_%28cryptographie%29#Dictionnaire_de_codes_:_.C2.AB_Electronic_codebook_.C2.BB_.28ECB.29)). Jussi Kivilinna n’est pas le seul à traquer la performance, et le noyau Linux 3.4 incorpore également [les _patches_ CRC32](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0292c497b6b942557d085b37f888ef5865f67d37) de Bob Pearson. Le [contrôle de redondance cyclique](http://fr.wikipedia.org/wiki/Contr%C3%B4le_de_redondance_cyclique) (CRC pour _**C**yclic **R**edundancy **C**heck_) est utilisé partout afin de détecter les erreurs de transmission, et il est important que le code soit optimisé soigneusement. Bob a modifié le fonctionnement de la routine `lib/crc32.c` afin de remplacer la boucle principale et la boucle `rem_le` par des compteurs à incrémenter. Selon les tests, on peut espérer un gain supérieur à 6 % sur architecture x86. Comme le code semble dégrader les performances des PowerPC, il a été entouré de `ifdef CONFIG_X86`, afin de ne pas pénaliser les autres architectures. ##Discard pour « thin provisioning » [Depuis le noyau 3.2](https://linuxfr.org/news/le-noyau-linux-3-2-est-disponible#toc_26), la couche _device mapper_ permet de faire de l’allocation fine et dynamique ([_thin provisioning_](http://fr.wikipedia.org/wiki/Dynamic_Provisioning)). Dans le cadre d’un [SAN](http://fr.wikipedia.org/wiki/R%C3%A9seau_de_stockage_SAN), plutôt que d’allouer vraiment tous les blocs à un client, on va les allouer à la volée pour économiser de l’espace. Chacun des clients aura un volume virtuel à sa disposition, mais ce volume n’occupera que l’espace réellement consommé. Cette cible DM de _« thin provisioning »_ est maintenant [capable de gérer](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=104655fd4dcebd50068ef30253a001da72e3a081) la fameuse fonction _discard_. Cette commande est très importante pour les disques de stockage de type SSD (à base de mémoire Flash), car elle permet au système d’exploitation d’indiquer au disque quels sont les blocs de données qui peuvent être effacés. Dans le cas du _thin provisioning_, un appel à _discard_ provoquera la suppression des correspondances (_mappings_) et, si les blocs ne sont plus partagés, l’ordre de suppression sera envoyé au périphérique sous‐jacent. Cette utilisation plus efficace du périphérique de stockage n’est pas la seule nouveauté intégrée dans la fonction de _thin provisioning_ du noyau 3.4. On trouve également [la possibilité d’utiliser des images en lecture seule comme origine](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2dd9c257fbc243aa76ee6db0bb8371f9f74fad2d). La lecture des blocs s’effectue sur cette image, tandis que les écritures se font sur un autre périphérique. C’est très utile dans le cas des environnements virtualisés, puisque l’hôte peut ainsi accueillir les systèmes invités sur un volume géré par _thin provisioning_, tout en ayant l’image de base stockée sur un autre périphérique partagé entre les machines virtuelles. ##IRQ domains Une IRQ c’est une demande [d’interruption](http://fr.wikipedia.org/wiki/Interruption_mat%C3%A9rielle) (_Interrupt Request_) envoyée au processeur pour lui signaler que le matériel a besoin qu’une action urgente soit effectuée (entrée‐sortie, avancement d’une horloge, défaut matériel, etc.). Linux se doit de gérer parfaitement les machines qui ont plusieurs contrôleurs d’interruptions et, pour atteindre ce but, un nouveau sous‐système nommé _IRQ domains_ fait son entrée dans le noyau 3.4. Auparavant c’étaient les fonctions `irq_alloc_desc` et `irq_free_desc` qui étaient utilisées afin d’éviter les collisions dans les assignations des numéros des interruptions. Ce mécanisme ayant été jugé perfectible (pas de possibilité de faire du _reverse mapping_), un nouveau système propre et générique a été développé. Il [s’inspire du code PowerPC](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c207f3a43194e108dda43dc9a1ce507335cff6b9) et s’active avec l’option de configuration `IRQ_DOMAIN`. Comme l’explique [la documentation](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7ab3a837adfc502913e0101d83bd3f4692b690b6), ce mécanisme générique permet maintenant au noyau Linux de gérer proprement la correspondance entre les IRQ des divers contrôleurs (_hwirq_) et l’espace global des interruptions. ##Pilote virtio-scsi [_Virtio_](http://fr.wikipedia.org/wiki/Virtio) est une interface virtuelle qui permet au noyau de gérer efficacement les entrées‐sorties pour les systèmes virtualisés. C’est le pilote `virtio-blk` qui s’occupe des périphériques en mode bloc, mais, à partir de ce noyau 3.4, [une alternative devient disponible](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4fe74b1cb051dc9d47a80e263c388cf1651783d4). Elle prend la forme du pilote `virtio-scsi` écrit par Paolo Bonzini, un développeur Red Hat. Ce pilote `virtio-scsi` propose le multiplexage (plusieurs [unités de stockage logiques](http://fr.wikipedia.org/wiki/Logical_Unit_Number) sur un seul port PCI), mais son auteur [le définit](http://article.gmane.org/gmane.comp.emulators.kvm.devel/86578) surtout comme plus extensible que `virtio-blk`. Avec ce dernier, il est nécessaire de définir la liste des fonctionnalités du périphérique, et chaque ajout implique une mise à jour de cette spécification, de l’hôte QEMU, ainsi que des pilotes des systèmes invités. Avec `virtio-scsi`, l’hôte fournit juste une couche de transport SCSI, et les ajouts de fonctionnalités se feront plus facilement (Paolo cite les fonctions _discard_, _extended copy_, ainsi que _write same_). Les développeurs Linux n’aiment pas vraiment introduire du code qui fait doublon dans le noyau, et Paolo a dû [batailler ferme pour convaincre James Bottomley](https://lkml.org/lkml/2011/12/7/100) de l’utilité de son pilote aux côtés de `virtio-blk`. Pour profiter de ce pilote alternatif sur vos systèmes, il vous faudra un noyau compilé avec l’option `SCSI_VIRTIO`. Ce code est encore considéré comme expérimental pour le moment. ##Du côté de -staging Pas mal de mouvements dans cette branche _-staging_ dédiée au code pas encore assez mature pour rejoindre la branche principale. Par exemple, les mécanismes _« zcache »_ et _« zram »_, qui s’occupent de compresser les pages mémoire, bénéficient d’un nouvel allocateur mémoire. Auparavant, c’était l’allocateur [_xvmalloc_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b154ff05e1b0d749231a71896c90e38657f8e675) qui était utilisé, mais [un remplaçant plus efficace](https://lwn.net/Articles/477067/) a été développé par Nitin Gupta. Ce nouvel allocateur se nomme [_zsmalloc_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=61989a80fb3ac9d7837d03053624d5ea034a0d02) et il est conçu tout spécialement pour stocker des pages RAM compressées et réduire la fragmentation. Par ailleurs, le mécanisme de compression _zcache_ [utilise maintenant](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=17dd9f831a3c70588d54cc3a24594f274f9ec3a1) le sous‐système `CRYPTO` du noyau pour son algorithme de compression. Avant, c’était un code _ad hoc_ qui était employé mais les développeurs Linux ont fermement indiqué qu’il fallait réutiliser le mécanisme standard. On peut choisir son algorithme au démarrage avec une syntaxe du type `zcache=lzo` ou `zcache=deflate`. Greg Kroah-‐artman [ayant indiqué](http://article.gmane.org/gmane.linux.kernel.mm/75481) qu’il n’accepterait plus aucun ajout de fonction, on peut penser que ces _patches_ seront les derniers avant la sortie de _-staging_ pour _zcache_ et _zram_. Toujours dans `-staging` les patchs écrits par Arve Hjønnevåg ajoutent [la prise en charge des alarmes Android](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=841cb11c6fc7ae559ef2d856932907056b75617d) dans le noyau. Encore un petit pas vers la gestion intégrale d'Android dans la branche principale. Le sous-système _« RAMster »_, après [un petit imbroglio initial](https://lwn.net/Articles/488540/), a également été intégré dans _-staging_ ([1](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b605c9621e57e72cbd45d59fd93d97b4a75c3597) - [2](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9a68e9a4c15d7b01f481010584fdeb66f2c0c49c)). L’idée derrière _RAMster_ est très intéressante, puisqu’il s’agit de permettre aux machines au sein d’une grappe de serveurs (_cluster_) de créer une sorte de réserve commune de mémoire vive. Ainsi, quand une machine est un peu juste en RAM et sur le point de devoir faire appel à la partition d’échange (le _swap_), elle va pouvoir envoyer ses données dans la RAM de sa collègue. Le mécanisme est toutefois complexe (voir la [documentation](http://oss.oracle.com/projects/tmem/dist/files/RAMster/HOWTO-v5-120214)) et il faudra attendre sa stabilisation avant de le voir intégrer la branche principale. Enfin, petit évènement, le dernier morceau du pilote de virtualisation [_Hyper-V_](http://fr.wikipedia.org/wiki/Hyper-V) écrit par Microsoft [quitte enfin](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=89ae7d709357df3a60e81c57613859d91d093ace) la branche _-staging_. Vous pouvez maintenant « profiter » de ce pilote en passant les options de configuration `HYPERV` et `HYPERV_STORAGE` lors la compilation. C’est la fin d’une [saga débutée en juillet 2009](https://linuxfr.org/news/microsoft-sort-un-pilote-hyper-v-pour-linux-sous-gpl), et qui, du fait des atermoiements et des problèmes de qualité du code, n’aura pas redoré le blason de la firme de Redmond. ##Pilote graphique Nouveau Pour faire une habile transition avec la brève précédente consacrée à _-staging_, notons [le _patch_ de Ben Skeggs](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f3c93cbde7eab38671ae085cb1027b08f5f36757), qui transfère le pilote [_Nouveau_](http://fr.wikipedia.org/wiki/Nouveau_%28informatique%29) de _-staging_ vers `drivers/gpu/drm`. Jusqu’à présent, les développeurs considéraient que Nouveau était encore susceptible de changer son interface binaire et donc devait rester dans l’antichambre du noyau. [Le passage en version 1.0](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f887c425f9eeed8ffbca64c8be45da62b07096c0) marque un engagement de stabilité et autorise maintenant une sortie de _-staging_. Comme l’écrit Ben : > _Il n’y a pas vraiment de raison de rester dans cette branche, de toute façon nous devons maintenir l’[ABI](http://fr.wikipedia.org/wiki/Application_binary_interface) pour éviter d’énerver les gens._ Ben a également [ajouté le code](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=68455a43debe26dd1d2a42c0b67dd5697c201420) permettant de faire fonctionner la toute récente carte de type Kepler (GeForce GTX 680). Attention toutefois, puisqu’il ne s’agit pas, pour l’instant, d’exploiter la puissance de cette carte, le _patch_ n’ajoute que la gestion des modes d’affichage ([_mode setting_](http://en.wikipedia.org/wiki/Modesetting)), ce qui permet d’éviter d’avoir à se rabattre sur VESA. ##Les autres pilotes graphiques Le pilote DRM dédié au système mono‐puce ([_SoC_](http://fr.wikipedia.org/wiki/_SoC_ "Définition Wikipédia")) Samsung [_Exynos_](http://en.wikipedia.org/wiki/Exynos) gagne une [prise en charge de la norme HDMI 1.4](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3ecd70b18cad5a5e04981f2a1d71e183f5d6ebc0) et un [pilote virtuel](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b73d12303ecfc91123363d8900e127da44bf42a6) permettant la gestion des écrans sans fil. Côté AMD, on voit arriver la prise en charge des cartes _Southern Islands_ (Radeon HD 7700, 7800 et 7900), ainsi que des processeurs _Fusion_ de type [_Trinity_](http://en.wikipedia.org/wiki/AMD_Fusion#.22Trinity.22.2C_.22Weatherford.22_and_.22Richland.22_.28all_32.C2.A0nm.29). Les cartes _Northern Islands_ [reçoivent des _patches_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=285484e2d55e76031b45926720c10b1aec8b782a) écrits par Jérome Glisse et permettant la prise en charge du pavage (_tiling_) 2D. Pour avoir une idée de la complexité du travail des développeurs de pilotes GPU, vous pouvez d’ailleurs aller lire [cette publication de Jérome](http://jglisse.livejournal.com/3472.html), dans laquelle il raconte la difficile traque d’un bogue affectant la sortie VGA des puces Llano. Du côté d’Intel, le pilote _i915_ [active enfin par défaut](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=aa46419186992e6b8b8010319f0ca7f40a0d13f5) le mode d’économie d’énergie RC6 sur les puces _Sandy Bridge_. On trouve également [la possibilité](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8f4839e21ea9a8f7300daac1fa30bfec514c9a25) d’entrelacer les flux HDMI et [SDVO](http://en.wikipedia.org/wiki/SDVO) en sortie, ainsi qu’une amélioration des performances d’environ 10 % grâce aux _patches_ [PGTT](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e21af88d39796c907c38648c824be3d646ffbe35) (_Per-process Graphics Translation Table_) et [_Swizzling_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f691e2f4cec334e906f971471b3bf1460c6256d4). ##HSI Le noyau 3.4 accueille [les _patches_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a056ab8c7a00a0ffc52e9573bf01257004c2d08c) de Carlos Chinea, qui travaille pour Nokia. Ils permettent la gestion du sous‐système [HSI](http://www.mipi.org/specifications/high-speed-synchronous-serial-interface-hsi) (_**H**igh Speed **S**ynchronous Serial **I**nterface_). Il s’agit d’un bus série utilisé dans les téléphones mobiles et destiné à faire communiquer les _« applications engines »_ (APE) avec le modem du mobile. HSI permet de multiplexer jusqu’à 16 canaux avec des latences faibles et une communication bidirectionnelle simultanée (_full‐duplex_). Pour l’instant, aucun pilote n’utilise ce nouveau bus série, mais Carlos [a indiqué](https://lkml.org/lkml/2011/10/28/69) qu’il travaillait sur le support d’une carte TI OMAP. D’autres développeurs ont manifesté leur intérêt auprès de Linus afin qu’il accepte ces _patches_ ([_Several people piped up to say "yeah, we want this"_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b1a808ff436343956a6ae63178ea1810c5e5a3a1)). ##Sous‐système remoteproc Les systèmes complets sur une puce ([SoC](http://fr.wikipedia.org/wiki/System_on_Chip)) contiennent souvent des cœurs de calcul très hétérogènes. Si l’on regarde par exemple le SoC [OMAP 4](http://en.wikipedia.org/wiki/OMAP#OMAP_4) de Texas Instrument, on constate qu’il est constitué de deux processeurs Cortex-A9, de deux processeurs Cortex-M3 et d’un DSP de type C64x. Comment faire dialoguer le plus proprement et le plus simplement possible ces divers cœurs de calcul ? C’est ici qu’entrent en scène le nouveau [sous‐système _remoteproc_](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=400e64df6b237eb36b127efd72000a2794f9eec1) et le [mode de communication _rpmsg_](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ac8954a413930dae3c53f7e782f09a94e7eae88b) qui ont été introduits dans le noyau 3.4. Le sous‐système _remoteproc_ permet au processeur principal de contrôler plus simplement les divers processeurs hétérogènes qui existent sur la puce SoC. C’est une sorte de couche d’abstraction du matériel, puisqu’il n’est plus besoin d’avoir des pilotes spécifiques pour gérer l’allumage (`rproc_boot`) ou l’extinction (`rproc_shutdown`) de ces processeurs spécifiques. En plus de cette simplification qu’apporte _remoteproc_ (voir [la documentation](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/remoteproc.txt;h=23ff7349ffe7faefbf48a844fd075b4c25ab55d2;hb=400e64df6b237eb36b127efd72000a2794f9eec1)), le bus _rpmsg_ intégré permet au pilotes noyau de communiquer facilement avec les cœurs hétérogènes via une interface de type [_virtio_](http://fr.wikipedia.org/wiki/Virtio). Un [pilote d’exemple](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=779b96d20ca97cfa19162b340bff0c27b405b4b2) utilisant le bus _rpmsg_ a été écrit par Ohad Ben-Cohen, afin de faciliter le travail des futurs utilisateurs. Le résultat net de ces changements c’est que les SoC peuvent maintenant disposer d’un sous‐système générique de contrôle et de communication entre leurs divers cœurs hétérogènes de calcul. Au lieu d’avoir une prolifération de pilotes variés, il suffira maintenant d’utiliser _remoteproc_, en ajoutant juste un peu de code bas niveau spécifique à la plate‐forme. ##Chargement retardé des pilotes Un mécanisme amélioré de chargement des pilotes lors du démarrage a été ajouté dans ce nouveau noyau 3.4. Dans les machines modernes, les périphériques sont devenus très complexes avec souvent plusieurs blocs fonctionnels interconnectés. L’ennui, c’est que dans ces configurations, il devient très difficile de déterminer l’ordre dans lequel les pilotes respectifs doivent être démarrés. Grant Likely, l’auteur du _patch_, [décrit ainsi le problème](http://article.gmane.org/gmane.linux.kernel/1163393) :> _Une « carte son » typique consiste en plusieurs périphériques : un ou plusieurs blocs _codecs_ (souvent attachés via [I2C](http://fr.wikipedia.org/wiki/I2C) ou [SPI](http://fr.wikipedia.org/wiki/Serial_Peripheral_Interface)), un bus son (souvent I2C), un contrôleur DMA et une certaine quantité de code spécifique à la machine/architecture afin de tenir tout ça ensemble._> _À l’heure actuelle, le code du noyau doit faire une vraie gymnastique afin d’enregistrer tous ces composants dans la couche son, et le pilote qui « tient tout ensemble » doit attendre que tous les autres pilotes soient chargés._ On voit donc qu’il s’agit là d’un problème de gestion des dépendances. Un pilote ne peut pas être chargé tant que les pilotes des autres composants ne sont pas déjà chargés. La solution semble donc simple : il suffit de déclarer une relation de dépendance entre les pilotes, comme on le fait pour les diverses options dans les fichiers `Kconfig` de Linux. Le problème c’est que cette solution consistant à déclarer les dépendances ne marche pas dans [le cas soulevé par Grant Likely](http://article.gmane.org/gmane.linux.kernel/1163393) et qui concerne les périphériques ayant plusieurs blocs fonctionnels interconnectés :> _Considérez le cas où un pilote A dépend d’une ressource [GPIO](http://fr.wikipedia.org/wiki/GPIO) qui est apportée par un pilote B. En théorie, il faudrait indiquer que le pilote A dépend du pilote B, mais, en fait, le pilote A n’a aucun moyen de savoir de quel pilote B il s’agit, puisqu’il est différent pour chaque système._ Ces « périphériques » ne sont plus vraiment des entités matérielles bien distinctes. Il sont formés à partir de nombreux composants séparés au niveau matériel et ne sont réunis que par une « glu » logicielle. La conséquence, c’est que le noyau Linux n’a aucun moyen de savoir quelles sont les dépendances entre ces composants tant que ceux‐ci n’ont pas commencé à dialoguer. Alors, comme dirait Lénine, que faire ? La solution de Grant Likely n’est pas d’une élégance absolue, mais elle constitue un progrès indéniable par rapport à la très vilaine collection de bidouilles qui est utilisée actuellement. Le _patch_ « [_driver probe deferral mechanism_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d1c3414c2a9d10ef7f0f7665f5d2947cd088c093) » permet tout simplement à un pilote de signaler qu’il n’a pas toutes les ressources nécessaires à son bon fonctionnement, et que son chargement doit être retardé afin d’être tenté à nouveau plus tard. Par exemple, un pilote [SDHCI](http://en.wikipedia.org/wiki/SDHC#SDHC) peut avoir besoin de la collaboration d’un contrôleur [I2C](http://en.wikipedia.org/wiki/I2c) [GPIO](http://en.wikipedia.org/wiki/GPIO) avant de pouvoir fonctionner correctement. Si le pilote du contrôleur est déjà disponible lors du chargement du pilote SDHCI, alors tout se passe bien et on ne change rien au comportement précédent. En revanche, si le pilote du contrôleur I2C n’a pas encore été chargé, alors un message `-EPROBE_DEFER` sera envoyé pour signaler le problème, et le pilote SDHCI sera mis dans une liste d’attente (_pending list_). À chaque chargement réussi d’un pilote, le ou les pilotes en attente seront testés de nouveau pour voir si leurs dépendances sont satisfaites. Comme indiqué dans [le message d’annonce sur la LKML](http://article.gmane.org/gmane.linux.kernel/1163373), c’est une approche _« low‐tech »_, mais qui a l’avantage d’être simple et de fonctionner correctement. ##Améliorations dans Perf L’outil de traçage intégré dans le noyau, `perf`, a été mis à jour avec de nombreuses nouvelles fonctions. Tout d’abord, les fonctions `top`, `stat` et `record` peuvent maintenant examiner des groupes de _threads_ ou de processus. Il suffit de fournir la liste des numéros de processus (PID) séparés par une virgule de cette façon : `perf top -p 21483,21485`. On peut également filtrer par utilisateur avec l’option `--uid`. Pour que `perf` se contente d’afficher les tâches tournant sous mon utilisateur, il suffira donc de faire un petit `perf top --uid patrick`. Une autre nouveauté est la possibilité de faire du profilage de précision au sujet des branches de code exécutées par le processeur. Cette fonction se base sur un module récent des processeurs Intel, le LBR (pour _**L**ast **B**ranch **R**ecord_). D’après les explications présentes dans [le message](http://article.gmane.org/gmane.linux.kernel/1270097) d’Ingo Molnar, il suffit d’activer la fonction avec `perf record -b` pour ensuite avoir la liste des branches qui sont exécutées le plus souvent par le processeur. Enfin, la fonction `report` de _perf_ dispose maintenant d’une interface graphique basique en GTK. Elle manque encore un peu de fignolage puisque, entre autres, il n’est pas possible de profiler un système KVM invité et qu’il n’y a pas de tri des colonnes, ni de code couleur pour les pourcentages. C’est toutefois un ajout bienvenu et qui va s’étoffer dans les versions suivantes du noyau. [Le _patch_](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c31a94570552dcaa517c4f7a043ffd28835016be) a été écrit par Pekka Enberg et la fonction s’active avec `perf report --gtk`. Bien entendu, c’est une occasion unique et inespérée d’ajouter pour la première fois ~~une nimage~~ une [copie d’écran](http://i.imgur.com/S93cu.png) dans une dépêche noyau : ![perf report](http://i.imgur.com/S93cu.png) #Statistiques En ce qui concerne les statistiques du cycle de développement du noyau 3.4, [le site LWN a publié son traditionnel article récapitulatif](https://lwn.net/Articles/496193/). En termes de _patches_, le total s’établit à 10 734 (au 11 mai), alors qu’il était de 10 449 pour le noyau précédent. Ce sont 1 271 développeurs différents qui ont contribué au moins un _patch_ dans ce cycle et, [comme la dernière fois](http://linuxfr.org/news/sortie-du-noyau-linux-3-3#toc_35), c’est Mark Brown qui est en tête de liste avec 284 _patches_. Si l’on classe les développeurs non plus en termes de _patches_ mais en termes de lignes modifiées, alors c’est Joe Perches qui occupe la première place. Il faut dire que Joe s’est attaqué à la remise en ordre du style de codage de nombreux fichiers, afin qu’ils respectent les conventions Linux. On trouve, parmi de nombreux autres, [ce _monstro‐patch_](https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=475be4d85a274d0961593db41cf85689db1d583c) de 10 000 lignes pour corriger les espaces et passer l’épreuve de `checkpatch` sans générer d’alertes : `314 files changed, 50359 insertions(+), 50455 deletions(-)`. C’est un travail ingrat, mais qui est incontestablement utile, puisqu’il apporte de l’uniformité dans le code source du noyau. Enfin, un coup d’œil sur le classement des entreprises montre une nouveauté assez étonnante. En effet, pour la toute première fois, Red Hat abandonne sa première place au profit d’Intel (seulement 960 _patches_ contre 1 138 pour la firme de Santa Clara). Linux n’était pas menacé par la monoculture, mais c’est toujours réjouissant de voir que le classement des top contributeurs évolue. Red Hat garde toutefois sa prééminence [en termes de _tags_ _« Signed-off »_](http://www.remword.com/kps_result/3.4_sof.html), parce qu’elle emploie de nombreux lieutenants de Linus.

AltStyle によって変換されたページ (->オリジナル) /