URL: https://linuxfr.org/news/sortie-de-linux-3-13 Title: Sortie de Linux 3.13 Authors: Martin Peres Davy Defaud, Jarvis, Romain Perier, Yves Bourguignon, Siosm, yogitetradim, Benoît Sibaud, ZeroHeure, jlh, antistress, Jiehong, claudex, JPEC, ariasuni, palm123, Mali, Dreamkey, jcr83 et Sylvhem Date: 2013年11月26日T11:37:37+01:00 License: CC By-SA Tags: kernel, linux, noyau_linux, coulisses, linus_torvalds, selinux et smack Score: 130 La sortie de la version stable 3.13 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site [_kernel.org_](https://www.kernel.org/). Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. ---- [Noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](https://www.kernel.org/) [Le détail des nouveautés sur kernelnewbies.org](http://kernelnewbies.org/Linux_3.13) [The Linux 3.13 Kernel Has Many Improvements](http://www.phoronix.com/scan.php?page=news_item&px=MTU2NDE) ---- # La phase de test ## RC-1 La version [RC-1](https://lkml.org/lkml/2013/11/22/439) a été annoncée par Linus le 22 novembre, avec 2 jours d’avance :> Donc, vous avez eu une semaine supplémentaire pour préparer vos demandes d’intégration, et si vous aviez l’intention de les envoyer durant les deux derniers jours en pensant que je fermerais la fenêtre de fusion le dimanche comme d’habitude, je ne peux que me moquer de vous et vous traiter de tous les noms. Parce que vos excuses ne m’intéressent pas. J’ai averti les gens à ce sujet dans les notes de la version 3.12. Comme prévu, quelques personnes y ont échappé de justesse aujourd’hui. Vous vous reconnaîtrez.>> S’il y a des demandes d’intégration que j’ai ratées (en raison des filtres à pourriel ou ne correspondant pas à mes habitudes de recherche normales), et si vous pensez que vous avez envoyé votre demande d’intégration dans les temps et que ça été oublié, prévenez‐moi — parce que je n’ai rien en attente à ma connaissance, mais des erreurs peuvent arriver.>> En parlant d’erreurs... Je suppose que c’était une erreur d’avoir cette semaine supplémentaire avant l’ouverture de la fenêtre de fusion, et j’aurais probablement dû faire un 3.12-RC8 à la place. Parce que les statistiques de _linux-next_ ont l’air suspectes, et nous avons eu des trucs supplémentaires à ce moment‐là et pas seulement durant la première semaine. Il est clair que les gens ont considéré que « nous allons avoir une semaine supplémentaire dans la fenêtre de fusion » et extrapolé un peu trop. Enfin, bon. Vivre et apprendre.>> Quoi qu’il en soit, mise à part cette petite bizarrerie, il s’agissait d’une fenêtre de fusion assez normale. À propos de la taille du correctif, c’est assez habituel : ~ 55 % de pilotes, 18 % de code d’architecture, 9 % de mises à jour réseau, et le reste est réparti (systèmes de fichiers, en‐têtes, outils, documentation). Au niveau fonctionnalités, les trucs les plus importants sont probablement les _nftables_ et le _multi‐queue block layer_, mais en fonction de vos centres d’intérêt, vous pourrez trouver toutes les mises à jour incrémentielles intéressantes dans les différents domaines. Il y a quelques impairs par‐ci, par‐là (gestion du mode LE du PowerPC...).>> Allez‐y et testez, et commencez à m’envoyer des corrections de régression. Et, vraiment, si vous ne m’avez pas envoyé votre demande de _« pull »_ dans les temps, ne vous plaignez pas. Parce que personne n’aimera un pleurnichard.>> Le résumé de la fusion suit. Le vrai rapport est trop gros pour être lisible, comme toujours pour une version RC1.>> Linus ##RC-2 La version [RC-2](http://lkml.indiana.edu/hypermail/linux/kernel/1311.3/03731.html) a été annoncée par Linus le 29 novembre :>Nous sommes revenus à un calendrier hebdomadaire normal, bien que j’envisage d’éventuellement le décaler pour une sortie de version dominicale. En attendant, c’est Noël tous les vendredis ! Ou, peut‐être, de manière plus appropriée, eu égard à la date, [[Hanoucca]].>>Bref, tout semble normal pour une -rc2. Rien d’extrêmement alarmant, de nombreuses petites corrections éparses et les statistiques semblent également normales (un peu plus de la moitié concernant les pilotes, le reste est pour un tiers des mises à jour d’architectures, un tiers de documentation et un tiers de divers — systèmes de fichiers, noyau, crypto...).>>Rien de particulier ne se distingue. Si la -rc1 vous faisait trop peur pour être testée, allez‐y maintenant. C’est sans problème.>>Linus ## RC-3 La version [RC-3](http://lkml.indiana.edu/hypermail/linux/kernel/1312.0/04539.html) a été annoncée par Linus le 6 décembre :> Je suis encore sur une planification de sorties le vendredi, bien que j’espère que cela change bientôt — la raison pour laquelle je n’ai pas laissé traîner cette sortie jusqu’à dimanche est qu’elle est déjà assez importante, et j’attendrai que les choses commencent à se calmer.>> Ce qui devrait vraiment arriver à ce point. Oh, oh. Je vais commencer à engueuler les gens qui m’envoient des trucs qui ne sont pas opportuns, comme nous avons déjà bien entamé les RC.>> Cela dit, ce n’est pas comme si cette RC3 était devenue énorme et ingérable, ou que quelque chose de particulièrement effrayant était arrivé. J’aurais aimé qu’elle soit plus petite, mais c’est toujours comme ça. Et rien de particulièrement déplaisant ne se démarque ici.>> Le plus gros des changements est pour les pilotes (réseau, SCSI, son et crypto...) et des choses pour ARM DT, mais aussi les trucs habituels comme les mises à jour d’architectures (PA-RISC, plus ARM, x86), des systèmes de fichiers et du réseau.>> Lâchez‐vous,>> Linus ## RC-4 La version [RC-4](http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/04939.html) a été annoncée par Linus le 15 décembre :> J’ai retardé de deux jours la sortie pour revenir au cycle normal de sorties le dimanche, mais je ne suis pas entièrement satisfait du résultat. Les choses ne se calment pas comme elles le devraient, la -rc4 est plus grosse que les précédentes -rc. Et je ne pense pas que ce soit seulement dû aux deux jours supplémentaires.>> De toutes façons, ce que cela veut dire en pratique, c’est que je vais devenir *très* ronchon vis‐à‐vis de quiconque m’envoyant d’inutiles merdes. Si ce n’est ni une régression, ni marqué pour la version stable, alors ne vous donnez même pas la peine de me l’envoyer. Car vous *seriez* traité de tous les noms, si vous ne suivez pas ces règles simples. _¿ Comprende ?_>>Bref, le gros des changements pour la -rc4 concerne les pilotes (notamment réseau et graphiques, mais il y a aussi de l’USB, les entrées et des mises à jour pilotes de media). À côté de cela, se trouvent les mises à jour usuelles d’architectures (principalement ARM) et les moins classiques mises à jour SELinux. Également au niveau du réseau, des ajouts çà et là pour une meilleure mesure. Le résumé des modifications n’est pas très concis, mais il a été ajouté pour votre bon plaisir.>> Évidemment, nous allons vers les vacances et j’espère vraiment que cela calmera aussi les choses pour les RC à venir...>>Linus ## RC-5 La version [RC-5](http://lkml.indiana.edu/hypermail/linux/kernel/1312.2/04604.html) a été annoncée par Linus le 22 décembre :>Ho, ho, ho,>>Noël est presque arrivé et la -rc5 est la dernière RC avant que la plupart d’entre nous ne se gorgent dans l’insensibilité ; ou pleurent dans nos bières solitaires ; ou sortent pour la nourriture chinoise ; ou ce que vous arrivez à faire.>>Les choses semblent se calmer lentement, et je m’attends à ce que la semaine prochaine soit encore plus calme pour des raisons évidentes. Cela pourrait aussi être un bon moment pour dire que même _si_ les choses continuent de se calmer, je pense que nous irons au moins jusqu’à la -rc8, puisque la [LCA](https://en.wikipedia.org/wiki/Linux.conf.au) est assez tôt cette année, et que je n’ouvrirai pas la fenêtre de fusion pour le 3.14 avant d’être rentré de ces voyages.>>De toute façon, à propos de la rc5 : environ 40 % de pilotes (graphiques, réseau, son, _divers-un-peu-de-tout_), 15 % de mises à jour d’architectures (cette fois, principalement du PowerPC), 10 % de systèmes de fichiers (Ceph/CIFS), 10 % de documentation, et le reste de « divers » incluant quelques corrections du cœur du noyau (ordonnanceur) et de la gestion de mémoire (NUMA). Rien de vraiment excitant ne ressort. Les bogues sur lesquels je suis intervenu étaient suffisamment subtils et inusuels pour que je ne ressente aucune alerte « drapeau rouge », comme je le voulais justement. Ce sont les bogues « Comment cela a pu seulement passer les tests superficiels ? » qui me rendent inquiet, et si ceux‐ci existaient, les gens seraient honteux et silencieux à propos d’eux. ;)>>Ainsi, malgré mon intention de faire traîner un peu la RC, il n’y a l’air d’avoir aucune raison technique réelle pour le faire, du moins jusqu’à présent. Tout se passe bien, donc, s’il vous plaît, sautez le pas et aidez à tester,>>Linus ##RC-6 La version [RC-6](http://lkml.indiana.edu/hypermail/linux/kernel/1312.3/01238.html) a été annoncée par Linus le 29 décembre :>Comme prévu, les choses ont été calmes durant cette semaine de vacances. Donc, diverses petites mises à jour aléatoires : pilotes (Infiniband, graphiques, _cpufreq_, _libata_, blocs), quelques petites corrections sur les systèmes de fichiers (ext4/JDB2), et quelques trucs sur les systèmes monopuces ARM. Minis corrections sur x86, _percpu_ et _cgroup_.>>Rien que vous n’auriez normalement seulement remarqué, juste 81 relativement petits _commits_.>>Linus ##RC-7 La version [RC-7](http://lkml.indiana.edu/hypermail/linux/kernel/1401.0/01214.html) a été annoncée par Linus le 4 janvier :>D’habitude, je fais ce genre de chose depuis l’aéroport lors de mon trajet de retour, mais puisque j’ai eu à réinstaller mon portable, j’ai eu peur et j’ai préféré le faire avant de partir, juste pour être sûr que tout soit bien installé sur le portable. Et, devinez quoi, la fois où je décide d’être prudent, tout a marché sans une égratignure...>>Bref, les choses ont été calmes et, si je n’étais en déplacement, ceci aurait été sans doute la dernière -rc. Rien ne justifie de retarder la sortie, même si il y a quelques correctifs en cours de discussion et de filtrage par les mainteneurs. Mais au lieu de faire une vraie 3.13 le week‐end prochain, je serai sur la route et n’ouvrirai décidément *pas* de fenêtre d’intégration. À la place, je ferai donc une RC8 la semaine prochaine, utile ou pas.>>Et, qui sait, peut‐être que quelque chose de critique apparaîtra au fur et à mesure que les gens émergeront lentement de leur coma alimentaire suite aux vacances. Mais, pour l’instant, j’ai l’impression que les choses vont bien.>>Dans cette RC, la moitié des mises à jour sont liées au réseau (à la fois des pilotes et du cœur) et le reste est un mélange d’autres pilotes (graphiques, entrées, cœur PCI et aussi d’autres correctifs épars) et des mises à jour d’architectures (s390 et PowerPC, ARM). Et encore des choses diverses (CIFS et GFS2, quelques trucs _mm_ d’Andrew, etc.).>>Mais, tout ceci est assez petit.>>Le résumé suit. Allez‐y, testez.>>Linus ##RC-8 La version [RC-8](http://lkml.indiana.edu/hypermail/linux/kernel/1401.1/02367.html) a été annoncée par Linus le 12 janvier :> Autre semaine, autre RC. Et c’est bien ainsi.>> La RC8 c’est l’habituel mélange avec « deux tiers de pilotes, un tiers divers », « divers » étant des mises à jour d’architectures (ARM et PA-RISC, cette fois‐ci) surtout dans le réseau. D’ailleurs, une grande partie des modifications de pilotes sont des pilotes réseau.>> Mais rien de particulièrement effrayant. La partie la plus effrayante de cette version est la lenteur de mon réseau. Le correctif est encore en cours de téléchargement, mais ça devrait être fait d’une minute à l’autre. Ou peut‐être une demi‐heure. Peu importe. Les répertoires _git_ ont été mis à jour depuis des heures, c’est juste les archives _tar_ et les correctifs (et cette annonce de version) qui ont été retardés par la mauvaise qualité du réseau.>> Espérons que les choses vont rester calmes, et que je pourrai finaliser le 3.13 la semaine prochaine quand je rentrerai à la maison. Mais, pour que tout fonctionne bien, les gars, nous devons tester. OK ?>> Linus # Les nouveautés ## Arch ### CPU Ces dernières années les supercalculateurs ont dépassé le nombre de 4 000 cœurs de calcul, le nombre de processeurs maximum se voit donc [augmenté de 4 096 à 8 192](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=6df1e7f2e96721dfdbfd8a034e52bc81916f978c). La présentation de la topologie matérielle au démarrage du noyau a également subi un [petit lifting](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=014d595c23f33dd8e2a996cc62239fb279047f1b). Avant, le système nous présentait les informations sous cette forme : smpboot: Booting Node 0, Processors #1 #2 #3 OK smpboot: Booting Node 1, Processors #4 #5 #6 #7 OK smpboot: Booting Node 2, Processors #8 #9 #10 #11 OK smpboot: Booting Node 3, Processors #12 #13 #14 #15 OK Brought up 16 CPUs Dès cette version, ces mêmes informations seront affichées de cette manière : x86: Booting SMP configuration: .... node #0, CPUs: #1 #2 #3 .... node #1, CPUs: #4 #5 #6 #7 .... node #2, CPUs: #8 #9 #10 #11 .... node #3, CPUs: #12 #13 #14 #15 x86: Booted up 4 nodes, 16 CPUs" ### Logging / Debug #### Perf Dans cette version, le système de compilation de l’outil _perf_ se voit amélioré. Désormais, la phase de compilation nécessite beaucoup moins d’étapes de la part de l’utilisateur. cd tools/perf make install De plus, celle‐ci s’exécute beaucoup plus rapidement car le système de compilation détecte le nombre de cœurs à la volée et lance une compilation en parallèle en conséquence. Pour mémoire, _perf_ est un outil de profilage dans Linux qui permet de superviser facilement les compteurs de performance. Les compteurs de performance sont des registres spéciaux dans le processeur qui permettent de compter les événements matériels qui ont lieu lorsque vous exécutez du code : le nombre de défauts de cache, le nombre d’instructions exécutées, les prédictions de branchements correctes ou incorrectes, etc. #### CPER La prise en charge de [CPER](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=340286cd4e9aff841affb897f6d2535ed27605cf) (_UEFI Common Platform Error Record_) ou également appelé _enhanced MCA logging_, disponible dans les derniers processeurs Xeon, a été ajoutée. Ces dernières années, le nombre de transistors dans les micro‐processeurs et les _chipsets_ mémoire a augmenté très rapidement. Le matériel est de plus en plus miniaturisé et contient de plus en plus de transistors. Ceci, avec la possibilité d’être touché par un rayon cosmique, augmente donc les risques de corruption de données. De plus, la défaillance matérielle reste toujours possible. Les puces électroniques modernes peuvent corriger certaines de ces erreurs par elles‐mêmes (sommes de contrôle ECC), mais il est parfois nécessaire que le système d’exploitation soit notifié de ce genre de problème, car le matériel ne peut pas le corriger lui‐même. C’est pour cette raison que les processeurs modernes mettent à disposition un mécanisme appelé MCA (_Machine Check Architecture_) qui permet, entre autres, au processeur de notifier le noyau des erreurs matérielles telles que les erreurs ECC, erreurs de parités, erreurs de caches, etc. Ce mécanisme est à base de registres spéciaux, dit MSR (_Machine Specific Registers_), afin de stocker les informations sur les erreurs rencontrées et de permettre au système de les traiter. Malheureusement les MSR sont extrêmement dépendants de l’architecture, sont limités en taille et sont parfois très difficiles à interpréter. CPER est une technologie d’enregistrement d’erreurs MCA gérée par le micrologiciel UEFI. C’est maintenant le micrologiciel qui va directement collecter les messages d’erreurs, les interpréter et les projeter en mémoire physique afin que le système d’exploitation puisse les analyser. Ceci va permettre, entre autres, de disposer d’un système de vérification d’architecture beaucoup plus portable, plus facile à maintenir et beaucoup plus riche en termes de rapports d’erreurs. Pour plus d’information, je vous invite à lire l’article [_Machine check handling on Linux_](http://halobates.de/mce.pdf) et le [_white paper_ d’Intel](http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/enhanced-mca-logging-xeon-paper.pdf) sur le MCA avancé dans les processeurs Xeon. #### Ktap L’outil _ktap_ a [presque été intégré](http://lwn.net/Articles/572788/) dans cette version. Une première fusion avait été faite avant d’être retirée, jugeant que la procédure de revue n’avait pas été respectée et que certaines rectifications devraient être faites avant que cela ne se produise. Son auteur a d’ailleurs dit qu’il était prêt à les faire. Peut‐être une fusion dans la 3.14 ? [_ktap_](http://www.ktap.org/) est un outil de débogage et de traçage dynamique. Il s’agit d’une machine virtuelle Lua embarquée dans le noyau Linux qui vient s’interfacer avec les outils de traçage existants. L’un de ses avantages est sa capacité à pouvoir injecter un script Lua de débogage directement dans le noyau, sans avoir à compiler quoi que ce soit, et de permettre de créer des routines de débogage sophistiquées simplement et rapidement. #### Earlyprintk avec UEFI La gestion du [_earlyprintk_ pour UEFI](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=69019d77c71472428a5d67ab8bb7cfa9145000d0) vient d’être ajoutée. Ceci permet d’envoyer des messages d’événements par le biais de la fonction _printk()_ du noyau beaucoup plus tôt, en déléguant l’affichage au tampon de trame vidéo ([_framebuffer_](http://fr.wikipedia.org/wiki/Framebuffer)) d’UEFI durant le début de la phase de démarrage. Utiliser le tampon de trame [[VESA]] n’étant pas possible sur les systèmes UEFI, il était donc nécessaire d’utiliser un lien série matériel pour pouvoir déboguer le noyau avant que le pilote graphique ne soit chargé. Les liens série matériels étant de plus en plus rares sur les ordinateurs récents, cette fonctionnalité donc est la bienvenue. _printk()_ est une fonction dans le noyau, comme _printf()_, mais qui permet d’envoyer des messages avec différents niveaux de criticités dans la console du noyau. Console dont vous pouvez ensuite retrouver le contenu à l’aide de la commande `dmesg`. #### Lockdep La prise en charge de [_seqcount/seqlocks_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=5e30025a319910695f5010dc0fb53a23299da14d) a été ajoutée à [_lockdep_](https://www.kernel.org/doc/Documentation/lockdep-design.txt). _Lockdep_ est le validateur de verrouillage du noyau, c’est un outil de débogage extrêmement utile. Il permet, en ajoutant un petite surcouche de code autour de chaque structure de donnée bloquante ([verrou tournant](http://fr.wikipedia.org/wiki/Spinlock "spinlock"), sémaphore, etc.), de savoir lorsqu’un verrou est pris ou relâché ou collecte des informations critiques, comme lorsqu’un processeur gère une interruption après avoir pris un verrou. Il permet également de détecter les cycles. Depuis son introduction en 2006, il a permis de supprimer énormément de bogues et d’[interblocages](http://fr.wikipedia.org/wiki/Interblocage) (_deadlocks_) dans le système. La prise en charge dans cette version a d’ailleurs permis de corriger quelques bogues. ### Ordonnanceurs et minuteurs #### Équilibrage NUMA automatique Dans cette version, la [gestion des politiques d’ordonnancement pour les architectures NUMA](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=39cf275a1a18ba3c7eb9b986c5c9b35b57332798) a été améliorée. Il est maintenant possible de placer un processus à côté de sa mémoire, ou encore de demander au système de placer deux processus qui partagent une page mémoire dans un même nœud. Des appels systèmes _sysctl()_ ont été ajoutés afin de pouvoir activer et désactiver ces politiques d’ordonnancement (_cf._ [modification de documentation](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=10fc05d0e551146ad6feb0ab8902d28a2d3c5624)). NUMA (_Non Uniform Memory Access_) est un système d’architecture sur les machines multi‐cœurs contemporaines qui permet de regrouper les cœurs de calcul par nœud. Les différentes zones mémoires sont ensuite séparées et accédées par différents bus placés respectivement sur chacun des nœuds. Ainsi, dans les systèmes disposant de beaucoup de cœurs, cela évite d’avoir un goulet d’étranglement sur le bus mémoire et d’impacter les performances de temps d’accès mémoire. L’impact visible de cette technique est que chaque cœur a une zone mémoire qui lui est directement attachée et qui est la plus performante. De ce fait, en fonction de la zone mémoire à laquelle un processus accède, sa mémoire locale ou la mémoire distante, ses performances en seront changées en conséquence. Il est donc important qu’un système d’exploitation tienne compte de cette topologie matérielle afin de placer un processus en cours d’exécution sur le bon nœud en fonction de la partie de la mémoire à laquelle il accède. Pour plus de détails, vous pouvez consulter [cet article de _LWN_](https://lwn.net/Articles/568870/). ### Consommation énergétique et ACPI La nouveauté principale liée à la gestion d’énergie est l’ajout de l’[infrastructure de limitation de consommation](http://thread.gmane.org/gmane.linux.kernel/1537719). Celle‐ci a pour objectif de limiter et de pouvoir répartir la consommation énergétique entre de multiples matériels. Pour l’instant, cette gestion semble limitée à Intel et sa technologie RAPL (_Running Average Power Limit_). À la base de RAPL se trouve un système de calcul de consommation énergétique basé sur un modèle du processeur et une instrumentation matérielle pour connaître quels blocs sont actifs à quel moment. À partir de cette information, il est ensuite possible de réduire la fréquence moyenne reçue par le processeur en ne laissant passer, par exemple, que 80 % des tics d’horloge. Cette réduction de fréquence permet de réduire la consommation moyenne du processeur et peut être modulée de sorte que le processeur consomme exactement ce que le système d’exploitation lui a demandé de consommer. Cette technique est très efficace pour les petits ajustements et pour sa réactivité face aux pics de charge, mais est sous‐optimale car elle nécessite une tension d’alimentation supérieure à ce qui était vraiment nécessaire pour atteindre le même niveau de performance. La tension d’alimentation est le principal facteur derrière la fuite de courant des transistors (consommation statique). Cette consommation statique participe à hauteur d’environ 50 % de la consommation globale d’un processeur moderne. Une fois RAPL combiné avec le changement de niveau de performance reprogrammant le contrôleur de tension et les générateurs d’horloge, RAPL permet de limiter très rapidement la consommation pour respecter une consigne tout en gardant une efficience proche de l’optimal. Intel utilise RAPL pour contrôler chaque cœur du processeur ainsi que la mémoire. NVIDIA [dispose d’un système équivalent](http://phd.mupuf.org/publication/2013/09/25/reverse-engineering-power-management-on-nvidia-gpus/) depuis les GeForce 8, mais ne s’en est jamais servi. Des indices laissent à penser qu’il pourrait cependant s’en servir pour les Tegra K1. [_Nouveau_](http://fr.wikipedia.org/wiki/Nouveau_%28informatique%29) ne peut pas vraiment s’en servir, car il faudrait calculer les paramètres du modèle matériel de la carte. C’est théoriquement possible, mais cela nécessite beaucoup de travail et du matériel spécialisé que l’équipe de _Nouveau_ ne possède pas. _Nouveau_ devrait cependant pouvoir utiliser un système plus lent à réagir sur les cartes équipées d’une sonde matérielle de consommation énergétique, lorsque le changement de fréquence dynamique sera géré. La gestion sera cependant réservée aux cartes de milieu et de haut de gamme Kepler. Pour plus d’informations concernant cette infrastructure, vous pouvez consulter cette [présentation](http://events.linuxfoundation.org/sites/events/files/slides/LinuxConPowerCapping_jpan.pdf) hébergée par la [Fondation Linux](http://www.linuxfoundation.org/). Le reste de la [demande d’intégration](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=f9300eaaac1ca300083ad41937923a90cc3a2394) concernant l’[[ACPI]] est majoritairement composé de correction de bogues et d’améliorations liées à _cpufreq_, l’implémentation du DVFS (_Dynamic Voltage and Frequency Scaling_, changement du voltage et de la fréquence en fonction de la charge) pour les processeurs. ## Pilotes graphiques libres ### Direct Rendering Manager (DRM) Peu de nouveautés dans DRM pour cette nouvelle version. La principale est l’extension de l’interface pour autoriser les clients à activer et désactiver des capacités. Cette extension a directement été utilisée pour exposer la 3D stéréoscopique, quand les écrans la gèrent. Pour le reste, on trouve une gestion des fichiers _sysfs_ plus résistante au chargement et déchargement des pilotes à chaud, une amélioration de la précision des horodatages des événements liés au _scan out_ (balayage de sortie vidéo) et beaucoup de corrections de bogues. Cette nouvelle version a été l’occasion de rappeler les règles pour l’apport de nouvelles fonctionnalités lorsque des modifications dans Linux, [_libdrm_](http://cgit.freedesktop.org/mesa/drm/) et [Mesa 3D](http://cgit.freedesktop.org/mesa/mesa/) (implémentation OpenGL libre) sont nécessaires. Ce rappel à l’ordre a été lancé par Dave Airlie, mainteneur de sous‐système DRM, après qu’un développeur d’Intel ait effectué un [_commit_](http://cgit.freedesktop.org/mesa/drm/commit/?id=6335e1d28c422050024bcf4100c4fb3a5bac2afb) dans _libdrm_ avant que son correctif pour Linux n’ait été accepté. Ce _commit_ a directement été [annulé](http://cgit.freedesktop.org/mesa/drm/commit/?id=da738d1ed0a0941a0cd061395ad86072171b3242) avec un court avertissement qui a été suivi par un courriel envoyé sur la liste de diffusion du projet Mesa 3D pour donner [plus de détails](https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg47389.html). Une courte discussion a suivi, certaines personnes critiquant l’idée que _libdrm_ n’ait pas de mainteneur, alors que d’autres trouvent que la situation actuelle est parfaite tant qu’une règle simple est respectée. Cette règle est que la prise en charge de cette fonctionnalité doit en premier lieu être ajoutée dans une branche officielle du noyau (au moins [_drm-next_](http://cgit.freedesktop.org/~airlied/linux/?h=drm-next)) avant de pouvoir ajouter la gestion pour cette fonctionnalité dans _libdrm_, puis dans Mesa 3D. C’est ce second choix qui a été retenu. ### Adreno (pilote msm) Le pilote écrit par Rob Clark, _msm_, pour les processeurs graphiques ARM [Adreno](https://developer.qualcomm.com/discover/chipsets-and-modems/adreno-gpu), que l’on trouve dans tous les processeurs [Snapdragon](https://developer.qualcomm.com/discover/chipsets-and-modems/snapdragon) de Qualcomm, se voit doté d’une prise en charge pour les nœuds de rendu ([_render nodes_](https://linuxfr.org/news/sortie-de-linux-3-12#render-nodes)), _Prime_ et les plans d’affichage KMS. _Prime_ est l’implémentation libre de la technologie [Optimus](https://fr.wikipedia.org/wiki/Optimus_(NVIDIA)) qui permet aux pilotes graphiques de pouvoir collaborer de façon à pouvoir effectuer le rendu d’une image sur un processeur graphique et l’afficher sur un autre. Les plans d’affichage KMS (_KMS planes_) sont à la base de la composition matérielle ([_compositing_](https://fr.wikipedia.org/wiki/Compositing)). Chaque plan est une image RVBA (ou équivalent) qui sera fondue avec les autres plans matériellement, au lieu d’utiliser les [_shaders_ OpenGL](http://fr.wikipedia.org/wiki/Shader). Cela permet d’augmenter les performances et/ou de diminuer la consommation énergétique. Pour plus d’informations, vous pouvez regarder la [demande d’intégration](http://www.spinics.net/lists/dri-devel/msg48101.html) de Rob Clark. ### AMD/ATI (pilote radeon) Cette nouvelle version du pilote _radeon_ pour les processeurs graphiques AMD/ATI active enfin par défaut le son pour les écrans HDMI. Elle ajoute aussi la gestion complète (gestion des modes d’affichage, décodage vidéo, gestion d’énergie) pour la famille de cartes _Hawaii_, dont les premières cartes sont sorties en octobre 2013. Côté gestion d’énergie, cette nouvelle version apporte la gestion de la mise en veille complète des processeurs graphiques discrets qui ne sont pas utilisées dans une machine gérant le PowerXpress (équivalent d’AMD à la technologie Optimus de NVIDIA). Elle apporte aussi la gestion du [DPM](https://linuxfr.org/news/linux-pour-workgroups-3-11-le-noyau-pret-pour-le-bureau#et-dpm-dans-tout-%C3%A7a) (_Dynamic Power Management_) à plus de cartes, et notamment aux familles _Southern Islands_ et _Hawaii_. Niveau performance, cette nouvelle version apporte un [énorme gain](http://www.phoronix.com/scan.php?page=article&item=linux_313_radeonsi&num=1) de 500 à 750 %, suivant les tâches, sur les processeurs graphiques de la famille _Southern Islands_ et _Hawaii_. La raison pour cette subite amélioration tient au fait que seul le premier moteur de _shaders_ était activé. Ce problème a été [diagnostiqué et corrigé](http://lists.freedesktop.org/archives/dri-devel/2013-December/050902.html) par le développeur d’AMD Marek Olšák. Cette nouvelle version du pilote est donc plutôt bénéfique pour les utilisateurs de cartes graphiques AMD récentes. ### Armada (pilote armada) Un nouveau pilote a fait son apparition dans DRM afin de gérer les processeurs graphiques des systèmes mono‐puces Marvell [_Armada_ 510](http://www.marvell.com/application-processors/armada-500/). Ce pilote est extrêmement complet pour une première version, puisqu’il gère deux écrans LCD, les plans d’affichage KMS, le commutation de pages pour les tampons graphiques dédiés à l’affichage et _Prime_ pour le partage de tampons graphiques entre clients et pilotes. Cependant, la fonctionnalité la plus importante est la gestion des tampons graphiques partagés par SHM, car ils permettent à _Armada_ et au pilote libre [_etna_viv_](https://github.com/laanwj/etna_viv) (vivante) de fournir une accélération graphique 3D libre. D’après son développeur, bien que ce pilote soit à destination des _Armada_ 510, la gestion de la série 610 devrait être facile à ajouter. ### Intel (pilote i915) Beaucoup de nouveautés chez Intel, avec notamment l’[introduction officielle de la gestion](http://www.spinics.net/lists/dri-devel/msg48511.html) des processeurs [_Broadwell_](https://en.wikipedia.org/wiki/Broadwell_(microarchitecture)) qui devraient être disponibles à la vente au 3^(e) trimestre 2014. Cette prise en charge est pour l’instant cachée derrière une option de compilation, mais à moins que vous ne travailliez pour Intel, vous ne devriez pas en avoir besoin. Une prise en charge suffisante pour être utilisable [arrivera dans Linux 3.14](http://blog.ffwll.ch/2014/01/neat-drmi915-stuff-for-314.html). Une autre nouveauté est le début de la gestion du [_Display Serial Interface_](https://en.wikipedia.org/wiki/Display_Serial_Interface) (DSI) de l’alliance [_Mobile Industry Processor Interface_](https://en.wikipedia.org/wiki/Mobile_Industry_Processor_Interface) (MIPI). Ce nouveau type de communication a pour but de réduire le coût des systèmes mobiles embarquant des écrans. DSI est disponible sur le Raspberry Pi. Toujours côté affichage, une prise en charge basique des écrans 3D a été ajoutée. La prise en charge grand public devrait être disponible assez rapidement dans Wayland (ce qui permettra de voir les engrenages d’_eglgears_ tourner en véritable 3D !) et la gestion de la mise à jour atomique des _sprites_ (pour le tatouage numérique) et du plan principal. Pour finir, le noyau exporte maintenant via _debugfs_ le contrôle de redondance cyclique ([CRC](http://fr.wikipedia.org/wiki/Contr%C3%B4le_de_redondance_cyclique)) des images après toutes les étapes de rendu (curseur, plans, _sprites_, correction de couleur et changement d’échelle). Cela va permettre d’automatiser des tests de rendu graphique. Un premier test sur les curseurs a déjà été écrit et a permis d’identifier et de résoudre plusieurs bogues. Du côté de la gestion énergétique, Intel n’a pas chômé en retravaillant son code de gestion du _power gating_ et en ajoutant notamment la gestion du [SWSCI](https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf), une infrastructure de gestion d’énergie pour les processeurs graphiques intégrés Intel. Cette gestion est nécessaire majoritairement pour Haswell dont le code de référence ACPI est très dépendant de SWSCI. Intel a également apporté la gestion du _boost / deboost_ logiciel qui devrait améliorer les performances et réduire la consommation dans les cas où la charge est relativement faible mais subit des forts pics d’activité, comme lors de la navigation sur le Web. Une partie des correctifs nécessaires pour l’ajout du _Per‐Process Graphic Translation Table_ (PPGTT) a aussi été intégrée dans cette version de Linux. Cela permet à différents processus graphiques de ne pas partager le même espace d’adressage graphique, ce qui devrait augmenter l’isolation entre les différentes applications. PPGTT sera disponible à terme sur les processeurs graphiques _Ivy Bridge_, _Haswell_, et _Broadwell_. Pour plus d’informations, vous pouvez consulter la [série de corretifs](http://lists.freedesktop.org/archives/intel-gfx/2013-June/029249.html) associée. ### NVIDIA (pilote nouveau) Dans cette nouvelle version du noyau, le pilote communautaire pour cartes graphiques NVIDIA n’a pas reçu beaucoup d’améliorations visibles, si ce n’est l’ajout de la gestion des modes d’affichage pour les puces NV108/GK208. La gestion complète de la carte sera introduite dans la version 3.14 du noyau. La prise en charge des interruptions [MSI](https://en.wikipedia.org/wiki/Message_Signaled_Interrupts) (_Message Signaled Interrupts_) a été activée par défaut afin de corriger des problèmes sur certaines nouvelles cartes pour lesquelles la méthode traditionnelle de gestion des interruptions n’était pas fiable. À l’inverse, avant cette version, plusieurs cartes ne géraient pas très bien les interruptions MSI, ce qui rendait le démarrage impossible. NVIDIA a [été contacté](https://www.mail-archive.com/nouveau@lists.freedesktop.org/msg14127.html) afin d’avoir des informations sur un potentiel _errata_ matériel. Entre‐temps, Ben Skeggs a investigué le problème et a trouvé par rétro‐ingénierie une solution pour les cartes problématiques connues. NVIDIA a confirmé la solution et a permis d’améliorer la gestion pour d’autres cartes qui n’étaient pas connues pour avoir de problèmes. L’équipe de _Nouveau_ a ensuite découvert que les cartes _nvaa_ et _nvac_ géraient mal les interruptions MSI, elles ont donc été désactivées. Depuis, il n’y a plus eu de rapport de bogue sur ce sujet. Du côté vidéo, la commutation de pages (_page‐flipping_) a été retravaillée pour corriger des bogues qui duraient depuis plusieurs versions. _Nouveau_ devrait donc moins souffrir du problème de cisaillement ([_tearing_](https://en.wikipedia.org/wiki/Screen_tearing)). La gestion de PMPEG a aussi été améliorée pour prendre en charge les NV40 à NV44. Les NV10 ont également reçu la gestion des plans d’affichage KMS permettant de faire de la composition (_compositing_) matérielle. Le gros du travail dans cette nouvelle version est lié à la gestion d’énergie, effectué par Ben Skeggs. Toute l’infrastructure a été repensée pour pouvoir prendre en charge le changement de fréquence dynamique, le _clock gating_ et le _power gating_. _Nouveau_ remplace maintenant le microcode du processeur concernant la gestion d’énergie PDAEMON/PPWR, ce qui veut dire que le pilote est maintenant responsable de la gestion du ventilateur sur _Fermi_. Ce microcode, écrit en assembleur Falcon/FμC, est un petit système d’exploitation temps réel qui permettra de décharger le processeur principal pour l’acquisition et le suivi de la charge de la carte, de la régulation du ventilateur et de la consommation. Outre le réusinage du code, Ben Skeggs a aussi corrigé beaucoup de bogues dans le changement de fréquence des moteurs d’exécution et de la sélection de la tension d’alimentation. Le changement de fréquence de la mémoire a également reçu beaucoup de correctifs, bien que le résultat ne soit toujours pas utilisable et ne le sera probablement pas avant plusieurs versions du noyau pour la plupart des cartes. Pour en finir avec la gestion d’énergie, la gestion complète du [changement de fréquence manuel pour les _nvaa/ac_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/nouveau?id=a7e4201f0f7d47e03b851f06f8987856e8d33083) (ION) a ensuite été contribuée par Roy Spliet. Ces puces sont intégrées et n’ont donc pas de mémoire vidéo. Ce sont actuellement les seuls puces pour lesquelles le changement de fréquence est officiellement pris en charge. Une prochaine version apportera le changement de fréquence dynamique, mais aucun développeur ne travaille actuellement dessus pour les cartes n’intégrant pas PDAEMON/PPWR. ### Poulsbo (pilote gma500) Le pilote _gma500_ pour les processeurs graphiques basés sur les PowerVR SGX 535 (aussi connus sous le nom d’Intel _Poulsbo_) a reçu les modifications nécessaires pour fermer un bogue relatif à l’hibernation datant d’il y a plus d’un an. Cette version apporte également la gestion de la [SVDO](https://en.wikipedia.org/wiki/Serial_Digital_Video_Out) aux [_Minnowboard_](http://www.minnowboard.org/) (équivalentes aux Raspberry _Pi_, mais basées sur des processeurs Intel Atom et avec un connecteur SATA). SVDO (_Serial Digital Video Out_ — sortie vidéo numérique série) est une technologie propriétaire d’Intel permettant d’ajouter des connexions VGA, DVI, SDTV, HDTV ou des récepteurs de télévision à travers un bus PCI express à 16 voies. ### Tegra (pilotes _host1x_ et _tegra_) Le pilote pour la version embarquée des processeurs graphiques NVIDIA (Tegra), a été ré‐architecturé pour être découpé en deux sous‐parties : _host1x_ et _tegra_. _host1x_ est un contrôleur [DMA](https://fr.wikipedia.org/wiki/Acc%C3%A8s_direct_%C3%A0_la_m%C3%A9moire) qui permet d’envoyer des commandes en asynchrone à différents composants graphiques et multimédias et de les faire se synchroniser grâce à l’utilisation de barrières (_fences_). Pour plus d’information, vous pouvez lire la [documentation](http://http.download.nvidia.com/tegra-public-appnotes/host1x.html) de NVIDIA à son sujet. Le code Tegra est la partie qui effectue les calculs graphiques. Jusqu’à présent, la partie Tegra se trouvait avec _host1x_ dans `/drivers/gpu/host1x/`. Elle a été déplacée dans `/drivers/gpu/drm/tegra` ce qui a permis de simplifier la procédure de démarrage de DRM. La gestion du Tegra 114 a ensuite été ajoutée dans les deux sous‐parties. _host1x_ a reçu les [modifications nécessaires](http://lists.freedesktop.org/archives/dri-devel/2013-October/047241.html) pour tenir compte d’un léger changement et de l’ajout d’un autre point de synchronisation. Tegra a, lui aussi, dû être légèrement modifié pour ajouter la [gestion du contrôleur d’affichage](http://lists.freedesktop.org/archives/dri-devel/2013-October/047155.html) et la [prise en charge du HDMI](http://lists.freedesktop.org/archives/dri-devel/2013-October/047323.html). Pour finir avec les nouveautés, la gestion de _gr3d_ a finalement été fusionnée. Ce qui veut dire que toutes les pièces côté noyau sont présentes pour permettre l’accélération 3D dans l’espace utilisateur. ### VMware (pilote vmwgfx) Pour le processeur graphique virtuel des machines virtuelles VMware, la prise en charge de _Prime_ [a été ajoutée](http://lists.freedesktop.org/archives/dri-devel/2013-November/048972.html). Cette prise en charge n’est pas complète, car elle ne permet pas le partage de tampons graphiques entre différents pilotes. C’est cependant suffisant pour permettre de gérer DRI3. ## Réseau ### nftables nftables est maintenant utilisable directement avec le dernier noyau. Vous pouvez consulter son [pull request](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=42a2d923cc349583ebf6fdd52a7d35e1c2f7e6bd). [_nftables_](http://linuxfr.org/news/nftables-successeur-diptables) est le successeur de _iptables_. Il permet de configurer le pare‐feu de Linux ([_netfilter_](http://fr.wikipedia.org/wiki/Netfilter)). Rappelons que _iptables_ et _netfilter_ ont été développés en 2001 pour le noyau 2.4, et que _iptables_ a peu évolué depuis. _iptables_ a beaucoup de limitations au niveau fonctionnel et au niveau du code : problème de la mise à jour des règles, de duplications de code qui entraînent des problèmes pour sa maintenance et pour les utilisateurs. Ainsi, pas mal de changements ont été entrepris pour _nftables_ afin de résoudre cela tout en fournissant une compatibilité pour les utilisateurs de _iptables_. Son développement s’est fait en deux temps : le développement a commencé avec Patrick McHardy, le chef de projet de [_netfilter_](http://fr.wikipedia.org/wiki/Netfilter), en 2008 et s’est poursuivi jusqu’en 2009. Une version _alpha_ du code a été présentée, malheureusement peu de monde a rejoint ce projet pour en finaliser le code. Le projet est alors resté en sommeil jusqu’en 2012 où son développement a repris grâce notamment à [Pablo Neira Ayuso](https://lwn.net/Articles/531876/). Pour plus de renseignements : * la présentation de _lwn.net_ en 2009 : [_Un nouvel espoir_](http://lwn.net/Articles/324989/) ; * le blog d’[Éric Leblond](http://linuxfr.org/users/regit) : [_nftables contre‐attaque_](https://home.regit.org/2013/03/pablo-neira-ayuso-nftables-strikes-back/) ; * la présentation de _lwn.net_ en 2013 : [_Le retour de nftables_](https://lwn.net/Articles/564095/) ; * un [article en français](https://kernel-recipes.org/fr/2013/nftables-quelles-motivations-et-quelles-solutions/) d’[Éric Leblond](http://linuxfr.org/users/regit) sur _kernel-recipes.org_ ; * le [site officiel de _nftables_](http://netfilter.org/projects/nftables/). ### En bref * [_TCP Fast Open_](https://lwn.net/Articles/508865/), qui avait été ajouté dans Linux 3.7, est maintenant [compilé par défaut](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0d41cca490c274352211efac50e9598d39a9dc80) ; * IPv6 : amélioration d’IPsec et ajout de [GSO/TSO](http://en.wikipedia.org/wiki/Large_segment_offload) ; * mobilité : ajout de l’implémentation de la couche pour la [communication en champ proche](http://fr.wikipedia.org/wiki/Communication_en_champ_proche) (_Near Field Communication_, NFC) utile, par exemple, pour les terminaux de paiement ; * haute disponibilité : * amélioration de l’[agrégation de liens](http://fr.wikipedia.org/wiki/Agr%C3%A9gation_de_liens) (_bonding_) concernant le mode tourniquet (_round‐robin_) et concernant la possibilité de mettre en place les options `mode` et `active_slave` via l’interface standard [_Netlink_](http://en.wikipedia.org/wiki/Netlink), * ajout de l’implémentation du protocole de redondance transparente de haute disponibilité ([_High-availability Seamless Redundancy_](http://en.wikipedia.org/wiki/High-availability_Seamless_Redundancy), HSR). HSR fournit de la redondance de basculement instantané pour les réseaux Ethernet. Cela demande une topologie en anneau (chaque nœud ayant deux interfaces réseaux). Ce protocole est adapté pour les applications qui requièrent de la haute disponibilité avec un temps de réaction très court. Pour plus d’information : * pour les anglophones : ; * pour les germanophones : . ## Systèmes de fichiers Une couche « multi‐file d’attente » (_Multi‐Queue Block Layer_) fait son apparition au sein du noyau. Celle‐ci est destinée à améliorer les opérations d’entrées‐sorties par unité de temps (_IOPS_), tout en réduisant la latence dans un système composé de multiples disques SSD et de plusieurs cœurs processeurs. Le noyau devrait maintenant essayer de mieux répartir la charge pour chaque cœur processeur tout en autorisant plusieurs files d’attente matérielles. On attend une augmentation des opérations d’entrées‐sorties d’un facteur allant de 3,5 à 10, et une réduction de la latence d’un facteur 10 à 38. Dans le même temps, il semblerait que [certains systèmes de fichiers soient plus lents](http://www.phoronix.com/scan.php?page=article&item=linux_313ssd_filesystems&num=1) que dans la version 3.12 du noyau. La cause de cette régression reste, pour l’instant, inexpliquée. ### Btrfs Miao Xie a permis de nettoyer le code de Btrfs, tout en améliorant les performances du mécanisme d’écriture différée (_write‐back_). Enfin, alors que Chris Mason ([à l’origine de Btrfs lorsqu’il travaillait pour Oracle](https://lkml.org/lkml/2007/6/12/242)) quitte son actuel employeur, la société [Fusion-io](http://en.wikipedia.org/wiki/Fusion-io), pour aller travailler au sein de Facebook, Josef Bacik entre officiellement dans la liste des mainteneurs de Btrfs ; le travail de Chris Mason pour Btrfs ne changera quasiment pas. ### F2FS À côté des habituelles corrections de bogues, F2FS améliore son ramasse‐miettes et les procédures de son verrou global. ### XFS & ext4 Le code d’ext4 est légèrement amélioré par quelques corrections de bogues tout en étant allégé. Quant à XFS, une partie de son code a été réusiné, et ses performances se sont améliorées. ## Sécurité ### Audit Les processus disposant de la capacité `CAP_AUDIT_CONTROL` pourront remettre à zéro (en fait -1, la valeur signifiant indéfini) le _loginuid_. Une fois que les outils de création de conteneurs (_systemd-nspawn_, LXC, _libvirt-lxc_) auront été modifiés, cela permettra aux conteneurs de fonctionner correctement avec le système d’audit, ne nécessitant donc plus de le désactiver au démarrage. Correctis : [1](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=81407c84ace88368ff23abb81caaeacf050c8450), [2](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d040e5af380554c23ffe0a034ae5f3e53da93a1d). Pour mieux comprendre ce changement, il faut revoir l’historique de _loginuid_. L’infrastructure d’audit permet, entre autres, de suivre les utilisateurs et les processus qu’ils lancent une fois qu’ils sont identifiés sur un système. Pour cela, l’UID utilisé lors de l’authentification est stocké (_loginuid_ dans la structure _task_struct_) de façon indépendante de l’UID courant. Cela permet de suivre les utilisateurs même s’ils changent d’utilisateur ou passent en _root_ avec `sudo`, par exemple. Cette opération de stockage du _loginuid_ doit être effectuée par le programme responsable de l’authentification d’un utilisateur sur un système. On utilise pour cela un module _pam_ spécifique : _pam_loginuid.so_. Au démarrage, les processus n’ont pas de _loginuid_ défini (-1). Avant le noyau 3.3, il fallait disposer de la capacité `CAP_AUDIT_CONTROL` pour pouvoir changer le _loginuid_. Il était nécessaire d’autoriser ces changements même si un _loginuid_ valide était déjà défini, car sinon un administrateur relançant le démon _sshd_ propagerait son _loguinuid_ à tous les utilisateurs se connectant via _ssh_. Mais ce n’est pas vraiment le comportement idéal, puisque l’on voudrait pouvoir définir ce _loginuid_ uniquement lors de l’authentification et ne plus autoriser aucune modification. Le noyau 3.3 introduit l’option [`AUDIT_LOGINUID_IMMUTABLE`](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=633b454), qui autorise n’importe quel processus à définir initialement son _loginuid_ sans avoir besoin de droits particuliers et empêche ensuite tout changement. Ceci est possible uniquement sur les systèmes utilisant _systemd_, car l’utilisateur ne lance ou relance plus lui‐même les services mais demande à _systemd_ de le faire. Le démon _sshd_ aura donc un _loginuid_ non défini (hérité de _systemd_) et pourra le définir pour un utilisateur à la connexion. Si un administrateur lance un démon _sshd_ à la main, le _loginuid_ ne sera pas changé et l’on pourra donc tracer l’origine de ce démon. Mais cette situation pose de nouveaux problèmes avec les conteneurs. En effet, cette fois, les conteneurs sont lancés par un utilisateur, donc le _loginuid_ est déjà défini, et les processus à l’intérieur du conteneur ne prenaient pas en compte cette situation. Les deux correctifs mentionnés ajoutent donc une interface qui contourne ce problème. L’option `AUDIT_LOGINUID_IMMUTABLE` a aussi été retirée ([_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83fa6bbe4c4541ae748b550b4ec391f8a0acfe94)), car jugée pas assez flexible. Une nouvelle option la remplace pour bloquer le changement de _loginuid_ à partir de l’espace utilisateur. ### IMA Il est maintenant possible de signer les fichiers avec [des algorithmes de hachage différents](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5278aa52f35003ddafda80b0243b3693f935b134) suivant l’importance accordée à l’intégrité du contenu par exemple. Pour ajouter cette fonctionnalité, il a été nécessaire, de modifier la [gestion des modèles IMA](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=adf53a778a0a5a5dc9103509da4a9719046e5310) qui décrivent l’organisation des données dans l’attribut de sécurité IMA. ### KEYS Modification des espaces de noms utilisateur (_user namespace_) pour pouvoir avoir un trousseau de clés, stocké dans le noyau, [distinct pour chaque espace de noms](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f36f8c75ae2e7d4da34f4c908cebdb4aa42c977e). Le [trousseau de clés noyau](http://lwn.net/Articles/210502/) fonctionne comme un cache et permet, entre autres, de stocker des clés de façon sûre et persistante jusqu’à leur expiration, même si l’utilisateur se déconnecte. Ce cache est particulièrement utile pour les tâches récurrentes _cron_ et [_Kerberos_](http://web.mit.edu/kerberos/krb5-devel/doc/basic/ccache_def.html). Ces clés peuvent maintenant être de [taille plus importante](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b2a4df200d570b2c33a57e1ebfa5896e4bc81b69) (potentiellement illimitée) et [être échangées (_swapped_) sur le disque dur](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ab3c3587f8cda9083209a61dbe3a4407d3cada10). ### Random Suite à une [analyse](http://eprint.iacr.org/2012/251.pdf) de la fonction chargée du mixage des sources d’entropie, [une modification a été effectuée pour l’améliorer légèrement](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e9fa2c8a630e6d0882828012431038abce285b9). Pour rappel, le noyau n’utilise pas directement les sources d’entropie dont il dispose pour générer des nombres aléatoires. Il mélange diverses sources pour s’assurer qu’une mauvaise source ne vienne pas réduire l’entropie finale obtenue. Cet [article](http://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator) sur le _blog_ de _Cloudflare_ détaille le processus dans le noyau. Le fonctionnement de `/dev/random` a été [en partie revu](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0891ad829d2a0501053703df66029e843e3b8365) : l’entropie est moins gaspillée, mieux estimée et les performances sont améliorées. Les architectures non x86 bénéficient de l’utilisation d’un registre qui ne peut pas être utilisé pour la mesure précise du temps mais qui peut apporter un peu d’entropie. Le noyau affiche maintenant l’état d’initialisation de `/dev/urandom` et prévient s’il est utilisé avant qu’il soit initialisé correctement. Ceci est fait en prévision d’un possible futur changement de comportement : le blocage de `/dev/urandom` si l’initialisation n’est pas terminée. D’autre modifications ont été effectuées pour `/dev/urandom`, elles sont détaillées dans [ce courriel récapitulatif](http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/04772.html). Des améliorations diverses et l’ajout de la prise en charge de nouveaux générateurs de nombres aléatoires ont également été inclus ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=26b265cd29dde56bf0901c421eabc7ae815f38c4)). ### SELinux Pour les systèmes de fichiers ne gérant pas les attributs étendus, un contexte SELinux est généré en fonction de la politique ou des options passées lors du montage. [Une petite modification](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5c73fceb8c70466c5876ad94c356922ae75a0820) autorise maintenant le changement du contexte de sécurité d’un fichier lorsque celui‐ci est dans un système de fichiers racine en mémoire ([ramfs](https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt)). La fonction chargée de la vérification de la validité de la partie multi‐niveau d’un label de sécurité (MLS) a été [fortement optimisée](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fee7114298cf54bbd221cdb2ab49738be8b94f4c). Il a été ajouté une [capacité pour la politique de sécurité](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2be4d74f2fd45460d70d4fe65cc1972ef45bf849) indiquant que les opérations réseau devront toujours être vérifiées par SELinux, même si les règles adéquates de filtrage et marquage des paquets ne sont pas chargées dans _netfilter_. Cela permet de protéger le système si les règles de filtrage ne peuvent pas être chargées à cause d’une erreur ou si elles sont vidées par un programme malicieux. La partie correspondante en espace utilisateur a déjà été intégrée l’année dernière. ### SMACK Un nouveau [mode d’accès](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c0ab6e56dcb7ca9903d460247cb464e769ae6e77) a été introduit pour différencier la pose d’un verrou sur un fichier d’une opération d’écriture. En effet, la pose d’un verrou en lecture sur un fichier ne nécessite pas d’avoir les droits d’écriture sur celui‐ci, juste les droits de lecture. Ainsi, deux programmes pourraient potentiellement discuter par l’intermédiaire d’un fichier dont ils ont tous les deux seulement accès en lecture. C’est un canal d’information caché, et typiquement le genre de situation que l’on souhaite éliminer dans le cadre d’un contrôle d’accès obligatoire. SMACK nécessitait donc d’avoir les droits en écriture (avec les labels SMACK, pas juste le DAC) pour pouvoir poser des verrous en lecture, ce qui cassait le comportement de nombreux programmes puisque c’était une situation inattendue (et la solution n’était pas acceptable d’un point de vue sécurité). Pour résoudre ce problème, le mode d’accès `lock` permet de poser des verrous en lecture, et il faut avoir l’accès `write` pour les poser aussi en écriture. Cela évite donc de donner trop de droits à un processus sur certains fichiers. Le crochet (_hook_ LSM) lié à _ptrace_ a été précédemment séparé pour permettre un contrôle plus fin des opérations effectuées. SMACK n’en profitait pas totalement, c’est maintenant [corrigé](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b5dfd8075bc26636d11c3d8888940198afbf5112). ### x86 Le noyau et l’espace utilisateur échangent couramment des données. Pour des raisons d’intégrité du noyau, il est important de vérifier que seules les données voulues par le noyau sont copiées en espace noyau. Pour des raisons de confidentialité, il est aussi important de vérifier que seules les données dont l’espace utilisateur a besoin sont rendues accessible à celui‐ci. Pour ces raisons, le noyau a des tests pour vérifier les bornes des opérations de copie depuis et vers l’espace utilisateur. Jusqu’à présent, ces opérations étaient vérifiées statiquement, à la compilation. Ces tests étaient cependant pleins de faux positifs dans le cas où la taille des données copiées était dynamique, surtout lorsque l’option `DEBUG_STRICT_USER_COPY_CHECKS` était activée. Pour résoudre ce problème, les tests pour les tailles dynamiques ont été [déportés à l’exécution](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=ae795fe760e20a7c6ad0f2cd24fc31afad73f427). ## Virtualisation ### Hyper-V La partie du pilote Hyper-V (l’hyperviseur de Windows) voit l’ajout d’un pilote de clavier. ### KVM [Pour KVM](http://lkml.indiana.edu/hypermail/linux/kernel/1311.1/03528.html), il y a un peu plus de changements, il est désormais possible d’avoir la virtualisation qui utilise l’émulation et l’hyperviseur en même temps sur le même noyau. Pour les processeurs Intel, la virtualisation imbriquée s’améliore et ARM gère les _transparent huge pages_, une amélioration du _overcommit_ et la prise en charge des invités « gros boutistes ». Il y a aussi une nouvelle interface pour [connecter KVM à l’aide des VFIO](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ec53500fae421e07c5d035918ca454a429732ef4), ce qui permet aux utilisateurs des _NoSnoop PCI transactions_ d’avoir un invité qui peut exécuter les instructions WBINVD, utiles notamment pour les pilotes NVIDIA sur Windows. ### Xen Dans cette version, Xen a reçu beaucoup de corrections de bogues et deux fonctionnalités majeures. La première est un système de traçabilité qui a été ajouté au pilote Xen [SWIOTLB](http://blog.xen.org/index.php/2013/08/14/swiotlb-by-morpheus/). La seconde est la prise en charge de la traduction d’adresse d’une machine physique vers une machine virtuelle, et inversement, sur les processeurs ARM 32 et 64 bits. Cela permet aux machines virtuelles de programmer des transferts DMA depuis des périphériques réels sur les systèmes sans IOMMU. Pour plus d’informations, vous pouvez consulter la [demande d’intégration de Xen](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86?id=eda670c626a4f53eb8ac5f20d8c10d3f0b54c583). # Le bilan en chiffres En ce qui concerne les statistiques du cycle de développement du noyau 3.13, le site _LWN.net_ a publié son traditionnel [article récapitulatif](https://lwn.net/Articles/579081/). En nombre de modifications, on se situe, avec 12 122 correctifs, au‐dessus de la version 3.12 (10 966 correctifs) et de la version 3.11 (10 893 correctifs), selon les [chiffres du site _www.remword.com_](http://www.remword.com/kps_result/3.13_petop.html). C’est un chiffre anormalement élevé, seuls trois noyaux ont fait mieux (2.6.25, 3.8 et 3.10). L’augmentation du nombre de développeurs différents est cependant plus faible, elle s’établit pour cette version à 1 412 contre 1 374 pour la version précédente, et 1 306 pour l’antépénultième. Les contributeurs les plus prolifiques de ce cycle sont Sachin Kamat, auteur de 361 modifications et Jingoo Han, à l’origine de 323 modifications, grâce à leur travail de nettoyage du sous‐système des pilotes. Ils sont suivis par Marcel Holtmann, 225 modifications, pour son travail sur la pile Bluetooth. Viresh Kumar loupe le podium de peu avec 169 modifications pour son travail sur le sous‐système _cpufreq_, tandis que H. Hartley Sweeten finit avec 150 modifications, après son développement sur les pilotes d’entrées‐sorties industrielles et les pilotes audio. Au moins 217 entreprises ont contribué à l’élaboration de cette version. Le podium est partagé par Intel (1 428 modifications), Linaro (1 166) et Red Hat (1 082). Notons que les contributeurs sans affiliations représentent 1 323 modifications, ce qui les place entre Intel et Linaro. # Appel aux volontaires Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition : | | Mainteneur | Contributeur(s) |--------------------------------|----------------------------------------------------|---------------- |**La phase de test** | Aucun | [_Jarvis_](https://linuxfr.org/users/jarvis), [_antistress_](https://linuxfr.org/users/antistress), [_yogitetradim_](https://linuxfr.org/users/yogitetradim), [Yves Bourguignon](https://linuxfr.org/users/biomin), [_Peck_](https://linuxfr.org/users/jpec), [_sinma_](https://linuxfr.org/users/sinma), [jlh](https://linuxfr.org/users/jlh), [_jcr83_](https://linuxfr.org/users/jcr83) | |**Arch** | [Romain Perier](https://linuxfr.org/users/rperier) | [Martin Peres](https://linuxfr.org/users/mupuf) (ACPI) | |**Pilotes graphiques libres** | [Martin Peres](https://linuxfr.org/users/mupuf) | aucun |**Réseau** | aucun | [Jarvis](https://linuxfr.org/users/jarvis) | |**Systèmes de fichiers** | [_Jiehong_](https://linuxfr.org/users/jiehong) | [_antistress_](https://linuxfr.org/users/antistress) | |**Sécurité** | [Timothée Ravier](https://linuxfr.org/users/siosm) | [Martin Peres](https://linuxfr.org/users/mupuf) | |**Virtualisation** | [Xavier Claude](https://linuxfr.org/users/claudex) | [Martin Peres](https://linuxfr.org/users/mupuf) (Xen) | |**Édition générale** | aucun | [Martin Peres](https://linuxfr.org/users/mupuf), [_Jarvis_](https://linuxfr.org/users/jarvis), [Yves Bourguignon](https://linuxfr.org/users/biomin), [_jlh_](https://linuxfr.org/users/jlh) | Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps. Si vous aimez ces dépêches et suivez l’évolution technique du noyau dans une partie, veuillez contribuer votre expertise au reste de la communauté. C’est un travail important et très gratifiant, qui permet aussi de s’améliorer. Essayons d’augmenter la couverture sur les modifications du noyau ! De plus, comme vous pouvez le voir, certaines parties n’ont pas de mainteneur (phase de test, réseau, édition générale). Un mainteneur est une personne qui est responsable de la qualité de sa partie et qui suis le développement de versions en versions. Ça vous intéresse ? Faites partie de l’équipe à long terme ! Actuellement, la partie « phase de test » reçoit la majorité des contributeurs, alors que les autres parties sont parfois le travail d’une personne unique. Nous espérons que l’ajout de cette catégorie permet de remercier plus spécifiquement les contributeurs et les motivera à se dépasser dans le futur, pour le bien de tous, eux y compris.

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