URL: https://linuxfr.org/news/sortie-de-linux-3-16 Title: Sortie de Linux 3.16 Authors: Martin Peres Davy Defaud, Siosm, JPEC, palm123, Romain Perier, jcr83, BAud, Nils Ratusznik, Jiehong, Albert_, Mali, claudex, glennie, cosmocat, Melkor73, Sytoka Modon, rpnpif, Jarvis, pamputt, sebas, Benoît Sibaud, Ymage, Nÿco, M5oul, Dams Nadé, EdB et kp Date: 2014年06月11日T14:50:40+02:00 License: CC By-SA Tags: btrfs, selinux, smack, lwn, kernel, linux et noyau_linux Score: 71 La sortie de la version stable 3.16 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. ---- [Les noyaux précédents](http://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](http://www.kernel.org) [LWN : The 3.16 merge window concludes](http://lwn.net/Articles/602212/) [Kernel-Log – Was 3.16 bringt (1): Storage & Netzwerk](http://www.heise.de/open/artikel/Kernel-Log-Was-3-16-bringt-1-Storage-Netzwerk-2244446.html) [Kernel-Log – Was 3.16 bringt (2): Infrastruktur](http://www.heise.de/open/artikel/Kernel-Log-Was-3-16-bringt-2-Infrastruktur-2261539.html) [Kernel-Log – Was 3.16 bringt (3): Treiber](http://www.heise.de/open/artikel/Kernel-Log-Was-3-16-bringt-3-Treiber-2267746.html) [Linux 3.16 sur kernelnewbies.org](http://kernelnewbies.org/Linux_3.16) [The Best Features Of Linux 3.16](http://www.phoronix.com/scan.php?page=news_item&px=MTc1NDM) [The New Features To The Linux 3.16 Kernel](http://www.phoronix.com/scan.php?page=news_item&px=MTcyMDU) ---- # En Bref ## Architecture * Unification de la hiérarchie des _cgroups_. ## Pilotes graphiques libres * AMD : meilleure performance et consommation plus basse grâce à BAPM ; * Intel : gestion des tampons graphiques alloués par _malloc()_ ; * Nouveau : changements de fréquence expérimental pour les processeurs graphiques Kepler. ## Réseau * _TCP Fast Open_ est maintenant disponible pour IPv6. ## Sécurité * Le bit _NX_ est maintenant utilisé plus tôt dans le chargement des modules. ## Virtualisation * KVM permet de gérer Xen en virtualisation imbriquée. # La phase de test ## RC-1 La version [RC-1](https://lkml.org/lkml/2014/6/16/1) est sortie le 15 juin 2014.> Cela fait deux semaines que la phase d’intégration a commencé et que la RC1 est prête. Par conséquent, la phase d’intégration est finie.> > Cette phase a été un peu inhabituelle, car cela fait seulement une semaine que la version 3.15 est sortie, et la première semaine a chevauché la dernière -RC de la version précédente ; mais cela ne semble pas avoir eu beaucoup de conséquences sur le développement. Tout semble normal et, s’il y a quelque chose à noter, c’est que cette phase a été plus grosse que d’habitude. Ce n’était tout de même pas une phase d’intégration aussi grosse que la 3.15, mais cela n’en était pas loin.> > Tout cela semble habituel du point de vue des statistiques : deux tiers des changements concernent les pilotes (et un tiers de ceux‐ci concernent *staging*), la moitié restante correspond à des mises à jour d’architectures (avec ARM en tête, principalement les fichiers [DTS](http://en.wikipedia.org/wiki/Device_tree "Device Tree Script") — mais il y a aussi du MIPS, PowerPC, x86 et ARM64).> > Mises à part les mises à jour de pilotes et d’architectures, un mélange habituel de changements : systèmes de fichiers (principalement ReiserFS, XFS, Btrfs, NFS), réseau, parties du *cœur* (_mm_, verrous, ordonanceur, traçage) et outils (performance et alimentation, mais aussi quelques tests).> > Comme d’habitude, le résumé court des changements est beaucoup trop long pour être utile et inclus dans cette annonce ; mais, naturellement, vous pouvez regarder le détail dans Git. Je poste les « changements fusionnés » comme d’habitude, ce qui donne, je pense, une meilleure vision générale. Et, comme d’habitude, cela ne reflète pas nécessairement les honneurs dus aux personnes qui ont écrit le code, mais aux mainteneurs des sous‐systèmes qui me les ont envoyés. Pour les vrais honneurs, allez voir dans l’arbre de Git.> > En avant, testez,> > Linus ## RC-2 La version [RC-2](https://lkml.org/lkml/2014/6/22/5) est sortie le 21 juin 2014.> C’est un jour plus tôt que d’habitude, mais demain cela risque de ne pas être possible pour moi, car je serai sur la route une bonne partie de la journée, donc allons‐y. Ces temps‐ci, la plupart des personnes envoient leurs demandes d’intégration et leurs correctifs pendant la semaine, donc ne pas publier un dimanche ne fera pas beaucoup de différence. De plus, ce n’est pas comme si je n’avais pas assez de modifications pour publier la RC2.> > Bon, assez d’excuses. La 3.16-rc2 a été publiée et contient l’assortiment habituel de correctifs répartis sur l’ensemble du code. Ce qui est inhabituel à ce stade est de constater à quel point les changements concernant l’architecture SPARC sortent du lot (presque 40 % des correctifs en vrac), mais ce ne sont que des nettoyages d’avertissements.> > De manière similaire, quelques modifications du DRM de Nouveau ressortent du côté taille. Mais, encore une fois, c’est principalement dû à des petites corrections de bogues de micro‐logiciels qui ont changé les fichiers générés. Les vrais changements sont peu importants.>> Si l’on ignore ces deux grosses modifications inhabituelles (en termes de lignes de code), le reste semble normal. Il y a des modifications de pilotes, des mises à jour d’outils (particulièrement _perf_) et diverses autres mises à jour d’architecture (ARM, s390, UNICORE32, x86...). Et juste des trucs divers un peu partout : _rtmutex_, Btrfs, bla bla bla.>> Le résumé de publication n’est pas minuscule, mais suffisamment petit pour être inclus ici, donc vous pouvez voir les détails si vous êtes intéressés.> > S’il vous plaît, testez‐le donc,>> Linus ## RC-3 La version [RC-3](https://lkml.org/lkml/2014/6/29/126) est sortie le 29 juin 2014.> Nous sommes de retour à un emploi du temps dominical de publication, et les choses semblent raisonnablement normales.> > Il y a peut‐être relativement moins de mises à jour de pilotes que d’habitude, dont la plupart sont assez petites, mais c’est probablement juste dû à la planification (par exemple, Greg n’a pas envoyé ses changements USB en *staging* cette semaine, donc les changements de pilotes sont principalement ceux des processeurs graphiques, du réseau et du son).> > De fait, les diverses mises à jour d’architectures (MIPS, PowerPC, x86, ARM) dominent dans les différences, et il y a quelques autres mises à jour diverses. Nous avons des mises à jour de systèmes de fichiers (AIO, NFS et OCFS2), un petit lot de corrections d’Andrew sur la gestion mémoire, quelques trucs réseau, etc.> > Le résumé de publication donne une bonne idée des changements. Les plus visibles pour les utilisateurs sont probablement le « dé‐cassage » des accès en lecture des périphériques à accès bloc sur les cibles 32 bits, et quelques corrections de régressions sur vDSO x86 qui posaient problème. Le reste n’affecte probablement, au final, que peu de personnes, mais ce sont des corrections appropriées...> > Linus ## RC-4 La version [RC-4](https://lkml.org/lkml/2014/7/6/150) est sortie le 6 juillet 2014.> Les choses se sont gentiment calmées et tout semble parfaitement normal. Peut‐être que ce calme a été dû, en partie, aux gens qui commencent à décoller pour l’été et (aux États‐Unis) la semaine du 4 juillet, mais quelle qu’en soit la raison, à la fois les journaux et les statistiques sur les modifications des fichiers semblent sympathiques et raisonnablement petits.>> La plupart des modifications concernent les pilotes (pilotes graphiques, USB, SCSI et son), les systèmes de fichiers (Btrfs, ext4) et les mises à jour d’architectures (principalement ARM). Avec une poignée de divers trucs épars. Mais cela reste relativement limité.>> Allez le tester,>> Linus ## RC-5 La version [RC-5](https://lkml.org/lkml/2014/7/13/187) est sortie le 13 juillet 2014.> Les choses ont l’air normales et, comme d’habitude, j’aurais aimé qu’il y ait un peu moins d’agitation, puisqu’il commence à être assez tard dans le cycle des versions candidates. Mais, honnêtement, ce n’est pas comme s’il y avait quelque chose qui fasse réellement froncer les sourcils.> > La plupart des modifications concernent les pilotes — avec ACPI et pilotes graphiques qui ressortent du lot. C’est vraiment assez varié ([HID](http://en.wikipedia.org/wiki/Human_interface_device "Human interface device"), moniteurs matériels, sous‐système [IIO](http://wiki.analog.com/software/linux/docs/iio/iio "Industrial I/O — E‐S industrielle"), capteurs de température, pilotes d’horloge, _libata_, _pinctrl_, etc.). Il y a les mises à jour d’architectures habituelles (principalement ARM et un peu de PowerPC), un peu de corrections pour la documentation DocBook et quelques corrections de systèmes de fichiers (F2FS, kernfs et ext4). Avec aussi une poignée de petites corrections du cœur (principalement les _cgroups_).> > En avant, testez,>> Linus ##RC-6 La version [RC-6](https://lkml.org/lkml/2014/7/21/6) est sortie le 20 juillet 2014.> Semaine après semaine, nous nous dirigeons vers ce qui est supposé être la dernière RC, mais, franchement, les modifications ne se calment pas comme elles le devraient.> > C’était déjà vrai pour la RC5 — plus grosse que la RC4. Cela ne m’avait pas inquiété outre mesure, parce que la RC4 était plutôt petite. Mais maintenant la RC6 est sortie, et elle est plus grosse que la RC5, et elle ne contient pas que des modifications triviales.>> Ce n’est pas comme cela que c’est supposé se passer.>> Quoi qu’il en soit, la RC6 n’est pas **si** grosse, donc je ne suis pas vraiment inquiet, mais j’en arrive au point où je vais commencer à insulter les gens et vous crier dessus, si vous m’envoyez des choses qui ne sont pas adéquates pour les dernières publications de RC. Ça ne veut pas dire que des gens l’ont fait : bien que la RC6 soit plus grosse que je le souhaitais, je ne pense pas qu’il y ait trop de choses manifestement frivoles dedans. Mais je vais continuer de garder un œil dessus, et je vais commencer à être grincheux (ou PLUS grincheux) si je remarque que les gens ne sont pas sérieux concernant le fait d’essayer de calmer les choses.>> Malgré tout, la RC6, elle‐même, finit par avoir des changements à peu près partout : pilotes (le principal étant du réseau, mais il y a du processeur graphique, il y a InfiniBand, nommez‐le comme vous voulez), les systèmes de fichiers (corrections NFS tardives, XFS, FUSE, GFS2, Btrfs), du code réseau de base, etc, etc. Ci‐joint le rapport résumé pour ceux qui sont intéressés par (un aperçu) des détails.>> Donc, allez récupérer la dernière RC et donnez un coup de pied dans les pneus, pour voir si rien ne passe entre les fissures. OK ?>> Linus ## RC-7 La version [RC-7](https://lkml.org/lkml/2014/7/27/111) est sortie le 27 juillet 2014.> Je suis content de dire que les choses se sont un peu calmées, et les choses semblent être sur la bonne voie.> > Ce qui n’était, en fait, pas du tout le cas au début de cette semaine — nous avions ce qui semblait être des bogues au cœur du code vraiment vicieux et, en plus du fait que la RC6 était plus grosse que les précédentes RC, je ne sentais vraiment pas bien cette publication pendant un moment.> > Mais les bogues les plus « méchants » n’étaient, au final, pas du tout des bogues du noyau. L’un venait en réalité d’une erreur de compilateur [NdT : la version de GCC de Debian était en cause](http://beta.slashdot.org/story/205139) (ce qui est toujours très effrayant, difficile à déboguer et très ennuyeux), et qui avait même une solution de contournement assez simple ce qui fait que nous n’avons pas eu à mettre des compilateurs sur listes noires. Un autre s’est avéré n’être qu’un faux positif, car _lockdep_ était un peu trop agressif.> > Nous avons évidemment **effectué** diverses vraies corrections là‐dedans, mais aucune n’a l’air spéciale ou inquiétante. Et la RC7 est finalement sensiblement plus petite que les RC précédentes, donc nous sommes clairement en train de nous calmer. Donc, contrairement à mes précédentes inquiétudes, ce pourrait être la dernière RC ; nous verrons comment la semaine prochaine se passera.> > En chiffres, la RC7 se compose d’environ un tiers d’architectures ([Xtensa](http://en.wikipedia.org/wiki/Tensilica#Xtensa_configurable_cores), PowerPC, x86, s390, [Blackfin](http://en.wikipedia.org/wiki/Blackfin)), un tiers de pilotes (pilotes graphiques, média, réseau) et un tiers de divers (réseau, gestion mémoire). Mais c’est assez petit. Journal résumé en pièce jointe.> > Linus ## Version finale La [version finale](https://lkml.org/lkml/2014/8/3/82) est sortie le 2 août 2014.> Alors, rien de spécialement intéressant ne s’est passé cette semaine, et la version 3.16 est arrivée.>> Et comme d’habitude (la version précédente faisant figure d’exception), cela signifie que la fenêtre d’intégration de la version 3.17 est évidemment ouverte. Pour la troisième fois consécutive, le calendrier craint, car j’ai un voyage à venir pendant la seconde semaine de la fenêtre. De nombreux autres développeurs principaux seront aussi en déplacement, car c’est juste avant le _Kernel Summit_ de Chicago.>> Donc nous verrons comment se passera la prochaine fenêtre d’intégration, mais je ne vais pas m’en préoccuper outre mesure. Si finalement je n’arrive pas à venir à bout des intégrations, je pourrai retarder dans la semaine du _Kernel Summit_, mais j’espère terminer la pluplart des grosses intégrations la semaine prochaine, avant tout départ en voyage, alors peut‐être qu’on n’en arrivera pas là. Il s’agit juste d’une information sur le fait que la fenêtre d’intégration **pourrait** être allongée.>> Quoi qu’il en soit, revenons aux changements depuis la RC7 : ce sont vraiment d’assez petits changements épars, avec un tiers de modifications d’architectures, un tiers de pilotes et un tiers de « divers » (principalement gestion mémoire et réseau). Les trucs d’architecture sont de petites mises à jour d’ARM (surtout DT), quelques corrections de Xen pour x86, et diverses petites choses pour PowerPC. Le journal résumé des changements donne une bonne idée de genre de truc que c’est, mais ça ne représente en réalité que 83 _commits_ (plus les fusions et le _commit_ de publication), et dont environ un tiers d’entre eux marqués comme stables.>> Bien que la version 3.16 ait semblé un peu incertaine pendant un moment, les choses se sont gentiment clarifiées, et il n’y avait aucune raison pour faire une version candidate supplémentaire comme je le craignais il y a quelques semaines.>> Linus # Les nouveautés ## Architecture ### Problèmes avec GCC 4.9 Un bogue assez pénalisant a été repéré au sein de l’ordonnanceur par des développeurs du noyau. Lorsque ce dernier était compilé en mode débogage, le compilateur _gcc_ ne compilait pas correctement la fonction `load_balance()` au sein de l’ordonnanceur, ce qui entraînait des comportements complètement inexplicables. Il s’agit d’un problème datant de _gcc_ 4.5 et qui se serait manifesté avec la sortie de _gcc_ 4.9 et 4.9.1, suite à l’activation de certaines optimisations. Le problème est maintenant corrigé dans la version de développement de _gcc_. En attendant, une solution de repli a été trouvée, il s’agit de compiler le noyau avec l’option ``-fno-var-tracking-assignments``, ce qui cache l’existence du bogue. Pour plus de détails, consultez le [_commit_](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=2062afb4f804afef61cbe62a30cac9a46e58e067). ### Unification de la hiérarchie des _cgroups_ L’architecture actuelle des _cgroups_ permet de créer plusieurs hiérarchies dans lesquelles on va pouvoir regrouper les processus et leur appliquer des restrictions lorsque ces hiérarchies sont spéciales, c’est‐à‐dire associées à des contrôleurs (options passées lors du montage). En pratique, cette hiérarchie est visible sous la forme d’un pseudo‐système de fichiers : ``` $ ls -l /sys/fs/cgroup total 0 dr-xr-xr-x 2 root root 0 Aug 7 01:52 blkio lrwxrwxrwx 1 root root 11 Aug 6 12:03 cpu -> cpu,cpuacct lrwxrwxrwx 1 root root 11 Aug 6 12:03 cpuacct -> cpu,cpuacct dr-xr-xr-x 2 root root 0 Aug 7 01:52 cpu,cpuacct dr-xr-xr-x 2 root root 0 Aug 7 01:52 cpuset dr-xr-xr-x 2 root root 0 Aug 7 01:52 devices dr-xr-xr-x 2 root root 0 Aug 7 01:52 freezer dr-xr-xr-x 2 root root 0 Aug 7 01:52 memory dr-xr-xr-x 2 root root 0 Aug 7 01:52 net_cls dr-xr-xr-x 4 root root 0 Aug 7 01:52 systemd $ tree /sys/fs/cgroup/systemd /sys/fs/cgroup/systemd ├── cgroup.clone_children ├── cgroup.procs ├── cgroup.sane_behavior ├── notify_on_release ├── release_agent ├── system.slice │ ├── cgroup.clone_children │ ├── cgroup.procs │ ├── dbus.service │ │ ├── cgroup.clone_children │ │ ├── cgroup.procs │ │ ├── notify_on_release │ │ └── tasks ... │ ├── home.mount │ │ ├── cgroup.clone_children │ │ ├── cgroup.procs │ │ ├── notify_on_release │ │ └── tasks ... ├── tasks └── user.slice ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release ├── tasks └── user-1000.slice ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release ├── session-1.scope │ ├── cgroup.clone_children │ ├── cgroup.procs │ ├── notify_on_release │ └── tasks ├── tasks └── user@1000.service ├── cgroup.clone_children ├── cgroup.procs ├── notify_on_release └── tasks ... ``` Ici, la hiérarchie _systemd_ n’est associée à aucun contrôleur, alors que les autres imposent des contraintes sur l’utilisation de la mémoire, du processeur... Tout ceci est donc très flexible mais difficile à gérer lorsque l’on veut modifier de façon cohérente les restrictions appliquées à un groupe de processus ou ajouter des restrictions à un groupe qui n’en avait pas auparavant. Cette complexité est avantageusement masquée par _systemd_, qui se charge actuellement de la gestion des _cgroups_ en proposant des options plus accessibles dans les fichiers d’_unit_ pour les services ([`systemd.resource-control` — _Resource control unit settings_](http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html)). Ainsi, il a été décidé de se débarrasser de cette séparation en plusieurs hiérarchies pour regrouper tous les contrôleurs dans une seule hiérarchie. Cela permet d’inclure dans l’architecture même de cette hiérarchie toutes les opérations que _systemd_ fait actuellement afin d’éviter cette complexité. Cette hiérarchie unifiée est disponible dans le noyau 3.16, mais elle n’est pas activée par défaut. Il faut monter le pseudo‐système de fichiers contrôlant les _cgroups_ avec les options : ``` $ mount -t cgroup -o __DEVEL__sane_behavior cgroup ``` Il est pour l’instant possible d’utiliser les deux hiérarchies simultanément pour tester le comportement de la nouvelle version, mais cela ne sera bien entendu plus possible dans les prochaines versions. Cette unification introduit aussi la notion de délégation : un processus privilégié (_systemd_) pourra déléguer le contrôle d’une partie de la hiérarchie à un autre processus, par exemple à un processus _systemd_ dans un conteneur (LXC, Docker, systemd-nspawn), voire à un processus _systemd_ pour la session d’un utilisateur. Plus d’informations sont disponibles dans l’article de _LWN_ ([_The unified control group hierarchy in 3.16_](http://lwn.net/Articles/601840/)), ainsi que dans la documentation officielle ([_Cgroup unified hierarchy_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/cgroups/unified-hierarchy.txt)) qui décrit notamment comment se servir de cette nouvelle hiérarchie. ### Système mono‐puce ARM (SoC ARM) Cette version intègre pas mal de nouveautés sur les plates‐formes ARM. La carte de développement [NVIDIA _Jetson TK1_](http://www.nvidia.fr/object/jetson-tk1-embedded-dev-kit-fr.html) dispose désormais d’un début de prise en charge. Il s’agit d’une carte embarquée dotée d’un processeur graphique NVIDIA _Kepler_ avec 192 cœurs [CUDA](http://fr.wikipedia.org/wiki/Compute_Unified_Device_Architecture "Compute Unified Device Architecture"), un processeur quadruple‐cœur basé sur l’ARM _Cortex A15_, 2 Gio de mémoire vive, USB 3, mini‐PCIe. Bref, une véritable machine de guerre. Les cartes NVIDIA _Tegra Note 7_ et _Shield_ sont intégrées à l’arborescence matérielle [_Device Tree_](http://www.devicetree.org/) (DT) et disposent également d’une prise en charge initiale pour cette version. La gestion multi‐plate‐forme des cartes Samsung _Exynos_ est désormais en place. Il s’agit d’une spécificité des plates‐formes ARM au sein du noyau Linux qui permet à une même image noyau de pouvoir s’exécuter sur différents systèmes mono‐puces ([SoC](http://fr.wikipedia.org/wiki/Syst%C3%A8me_mono-puce "System on a Chip")) d’une même famille de processeurs, ou à un même pilote de périphérique de pouvoir fonctionner sur différents matériels tout en gardant un cœur générique et indépendant de la machine ou de la carte embarquée sur laquelle il tourne. Cela évite de devoir mettre en dur dans le code des informations spécifiques au matériel. C’est notamment possible grâce à l’utilisation du [_Device Tree_](http://www.devicetree.org/). Les familles de processeurs ARM qui disposent de cette fonctionnalité sont de plus en plus nombreuses, on peut notamment citer : Samsung _Exynos_, Freescale _i.MX_, NVIDIA _Tegra_, Texas Instruments _OMAP_ ou encore ceux de Rockchip. Parmi les nouveautés les plus marquantes, nous pouvons également noter la gestion du _Symmetric MultiProcessing_ (SMP) pour les Marvell _Armada 375/38x_ et les Allwinner _A31_, ainsi que l’arrivée de la prise en charge de nouveaux systèmes mono‐puces : Freescale _i.MX6SX_, LSI _Axxia AXM55xx_ et Samsung _Exynos_ 3250, 5260, 5410, 5420 et 5800. Pour plus de renseignements concernant les nouvelles fonctionnalités ARM pour cette version, je vous invite à regarder le [_commit_](http://lkml.iu.edu/hypermail/linux/kernel/1406.0/00970.html) plus en détail. ### MIPS Pas mal de nouveautés sont au rendez‐vous pour l’architecture MIPS. La para‐virtualisation fait son apparition au sein de Linux 3.16. Le nombre maximum de processeurs se voit augmenté de 64 à 256. Il est maintenant possible d’éteindre la carte d’évaluation _Malta_, qui dispose d’un mode d’extinction logiciel (c’est‐à‐dire générique et non propre à la carte). Un début de gestion de l’_Octeon 3_ a également été ajouté. L’[Octeon 3](http://en.wikipedia.org/wiki/Cavium#OCTEON_III_SoCs) est le nouveau processeur de Cavium annoncé en fin d’année 2013. Il s’agit d’un processeur multi‐cœur basé sur les processeurs MIPS 64 bits, gravé en 28 nm et orienté calcul haute performance. Pour plus de renseignements, lire la [demande d’intégration](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=82abb273d838318424644d8f02825db0fbbd400a). ### ARM64 #### big.LITTLE dans cpufreq Une nouveauté assez intéressante est l’ajout du mode _big.LITTLE_ de la dernière famille de processeurs ARMv8 au sein du pilote CPUFreq. Le mode _big.LITTLE_ est une nouvelle technologie dite « d’optimisation de gestion de l’énergie » qui permet au processeur ARM de disposer d’un maximum de performances lorsqu’il en a besoin, tout en préservant au maximum son énergie lorsque cette puissance n’est pas nécessaire. Pour ce faire, le système mono‐puce est doté de plusieurs cœurs destinés au calcul intensif (_BIG_) et d’autres qui consomment moins d’énergie qui sont destinés à faire tourner les tâches moins gourmandes en ressources (_LITTLE_). Le système mono‐puce fait connaître ses cœurs de processeurs _BIG_ et _LITTLE_ au système d’exploitation afin que les tâches puissent migrer à chaud d’un cœur de calcul à l’autre en fonction de la charge du cœur sur lequel il se trouve, mais aussi en fonction de son « historique » logiciel d’exécution, ce qui permet à l’ordonnanceur de pouvoir anticiper ses décisions. Il ne s’agit là que d’une gestion au sein de CPUFreq lui permettant ainsi de décider quel cœur doit être activé et quel cœur doit être éteint, et ainsi gérer les « niveaux de puissance » (_power states_) en conséquence. Les futurs changements concernant l’ordonnanceur devraient voir le jour dans les prochaines versions. #### EFI Stub L’architecture ARM 64 bits dispose désormais de la gestion d’_EFI stub_. L’_EFI stub_ de Linux permet à un système disposant d’un micrologiciel (U)EFI de démarrer l’image du noyau directement sans avoir à passer par un chargeur d’amorçage (tel que GRUB ou [_elilo_](http://fr.wikipedia.org/wiki/Elilo)). Ceci est notamment possible en ajoutant du code au début de l’image du noyau afin de faire croire au micrologiciel (U)EFI qu’il s’agit d’une image de type PE/COFF, de cette façon le noyau se fait passer pour un exécutable (U)EFI. Pour plus de renseignements, voir la [demande d’intégration](http://lkml.iu.edu/hypermail/linux/kernel/1406.0/04053.html). #### AMD Seattle Le nouveau système mono‐puce ARM 64 bits _Opteron A1100_ d’AMD, baptisé _Seattle_, se voit pris en charge par cette nouvelle version du noyau. Il s’agit du premier système mono‐puce ARM de chez AMD, destiné à équiper les serveurs à basse consommation d’énergie dédiés à la gestion de données massives (ce qu’on appelle communément le « [_big data_](http://fr.wikipedia.org/wiki/Big_data) »). Cette puce comprend huit cœurs ARM _Cortex A57_ cadencés à plus de 2 GHz chacun, gère jusqu’à 128 Gio de mémoire vive, intègre la technologie ARM [TrustZone](http://en.wikipedia.org/wiki/TrustZone#TrustZone), un bus PCIe doté de huit voies, deux ports Ethernet 10 Gbit/s, de co‐processeurs cryptographiques et de compression‐décompression. Selon AMD, La série A de _Opteron_ irait jusqu’à deux à quatre fois plus vite que la série X et disposerait d’un bien meilleur rendement énergétique (rapport performance / consommation). Le meilleur étant, bien entendu, pour la fin : le prix ! ### x86 : Intel Broadwell dans P-State La future génération de processeurs de chez Intel, baptisée _Broadwell_ est maintenant [prise en charge](http://lkml.iu.edu/hypermail/linux/kernel/1405.3/04222.html) dans le pilote P-State. Pour rappel, P-State est le nouveau pilote Intel au sein du noyau Linux qui permet de contrôler plus finement les tensions électriques et les fréquences des éléments du processeur, afin gérer plus efficacement la consommation énergétique (notamment comparé au pilote de CPUFreq). ## Pilotes graphiques libres ### DRM (Direct Rendering Manager) Contrairement à Linux 3.15, le code commun aux pilotes graphiques libres (DRM) a reçu peu d’attention dans cette version. Les modifications les plus intéressantes dans l’immédiat sont une [mise à jour de la documentation](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm?id=f5752b38970990fa1495839751aed64bd178b9e0) et la correction d’une situation de concurrence (_race condition_) dans le nommage des connecteurs et des encodeurs. Pour finir, la gestion des verrous a été revue en préparation du travail sur la gestion atomique du mode graphique. Cette gestion atomique du mode graphique est un saint Graal en [discussion](http://www.x.org/wiki/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf) depuis au moins 2012. Une [présentation](https://archive.fosdem.org/2013/schedule/event/pageflip/attachments/slides/246/export/events/attachments/pageflip/slides/246/FOSDEM2013_atomic_modesetting.pdf) claire a été donnée au [_FOSDEM 2013_](https://archive.fosdem.org/2013/) qui explique l’intérêt d’avoir une interface transactionnelle pour la gestion du mode graphique afin de respecter le mantra de Wayland, qui est que toute image doit être parfaite, même lorsque l’on modifie des plans d’affichage graphique. Pour plus d’informations, vous pouvez consulter la [demande d’intégration DRM]( http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=682b7c1c8ea8885aa681ddf530d6cf2ad4f2dc15). ### Adreno (pilote msm) Peu de nouveautés pour Adreno dans cette nouvelle version, si ce n’est l’ajout d’outils de débogage à destination des développeurs. La nouveauté majeure est l’ajout d’une [gestion très partielle](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=70c70f091b1ffd16b3e1a439bd595f7d539b1d5d) des [compteurs de performance](https://en.wikipedia.org/wiki/Hardware_performance_counter), exposés dans [_debugfs_](http://en.wikipedia.org/wiki/Debugfs). Les compteurs exposés sont le temps d’activité du processeur graphique, _ALUACTIVE_ et _ALUFULL_. Toujours dans _debugfs_, il est [maintenant possible](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/msm?id=a7d3c9509b2fecf8e593f3c933ab302cbe987d2e) de récupérer les commandes envoyées avec les numéros de barrières (_fences_) associées. Il est aussi possible de connaître l’état des registres, afin de pouvoir retrouver quel groupe de commandes a planté le processeur graphique. Pour plus d’informations, vous pouvez consulter la [demande d’intégration _msm_](http://comments.gmane.org/gmane.comp.video.dri.devel/107313). ### AMD/ATI (pilote radeon) La nouveauté principale du pilote Radeon est l’ajout de la gestion du _Deep Color_. Au lieu d’utiliser 8 bits par composante (rouge, verte ou bleu), il est maintenant possible d’utiliser 10 ou 12 bits par composante pour les écrans qui le gèrent. Comme certains écrans disent, à tort, gérer cette fonctionnalité, celle‐ci a été désactivée par défaut jusqu’à ce que tous les bogues aient été corrigés. Si vous voulez tester cette fonctionnalité pour vérifier qu’elle n’ajoute pas de régression ou qu’elle fait ce qui est attendu, vous devez rajouter le paramètre noyau « ``deep_color=1`` » pour le module _radeon_. Une optimisation de la mémoire virtuelle pour la gestion des tampons graphiques situés dans le tableau de réadressage de la mémoire graphique (_Graphics Address Remapping Table_ — [GART](http://en.wikipedia.org/wiki/Graphics_address_remapping_table)) a été également été ajoutée à cette version pour les familles [_Southern Islands_](http://lists.freedesktop.org/archives/dri-devel/2014-May/060667.html) et [_Sea Islands_](http://lists.freedesktop.org/archives/dri-devel/2014-May/060683.html). Le programme d’évaluation [_Unigine Tropics_](https://unigine.com/products/tropics/) a mesuré un [gain de performances jusqu’à 34 %](http://www.phoronix.com/scan.php?page=article&item=linux316_radeon_boost&num=3). Des [corrections de bogues](https://bugs.freedesktop.org/show_bug.cgi?id=72921) ont imposé l’activation permanente du [BAPM](http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf) (_Bidirectional Application Power Management_) pour certaines puces graphiques d’AMD. Le BAPM est une gestion de la consommation énergétique plus fine (plus _granulaire_) remplaçant l’ancienne DPM (_Dynamic Power Management_) aux seuils de déclenchement plus larges. BAPM est désormais activée implicitement. Ce système agit sur la fréquence de fonctionnement de la puce qui peut passer rapidement, par exemple, de 3,4 GHz à 1,4 GHz par des seuils plus fins qu’avec DPM. Plus la fréquence est basse, moins on consomme. Malgré son caractère [expérimental](http://www.phoronix.com/scan.php?page=news_item&px=MTczMzI), cette fonction indispensable pour les portables et mobiles est désormais activée en permanence sur les puces de type _Trinity_, car ces systèmes plantaient souvent lorsque le DPM était activé. De même, le DPM classique activé (`radeon.dpm=1`) empêchait le démarrage des systèmes à base de puces compatibles ARUBA, même avec l’alimentation secteur, et principalement dans les [APU](http://fr.wikipedia.org/wiki/Accelerated_Processing_Unit). Non seulement, le BAPM a permis une meilleure gestion de l’énergie des puces ARUBA, mais il a également accru significativement leur performance. Pour plus d’informations, vous pouvez consulter les demandes d’intégration Radeon [[1](http://lists.freedesktop.org/archives/dri-devel/2014-June/061050.html)] et [[2](http://lists.freedesktop.org/archives/dri-devel/2014-June/061483.html)]. ### Intel (i915) La nouveauté principale du pilote Intel dans cette version est la possibilité pour une application de créer un tampon graphique à partir d’un tampon alloué avec `malloc()`. Cela permet d’éviter de faire des copies lors de transferts vers ou depuis le processeur graphique, et donc d’améliorer les performances en réduisant les latences. Jérôme Glisse [a réagi et exprimé son mécontentement](http://thread.gmane.org/gmane.comp.video.dri.devel/108960), car ce correctif change radicalement la gestion de la mémoire et est probablement peu sûr. Il a proposé une explication de comment une erreur pourrait se produire, mais le [correctif](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5cc9ed4b9a7ac579362ccebac67f7a4cdb36de06) a quand même été accepté. Celui‐ci devrait améliorer les performances des compositeurs graphiques en évitant la recopie des fenêtres exposées par mémoire partagée au compositeur. Le pilote _i915_ continue sa transformation progressive vers la commutation atomique de page mémoire (_atomic page flipping_) et l’exposition de ses plans d’affichage graphique, sans que ce soit pour l’instant utilisable par les utilisateurs. Cependant, il est maintenant possible d’utiliser des curseurs de 256 ×ばつ 256 pixels au lieu de 64 ×ばつ 64, ce que les possesseurs d’écrans à haute densité de pixels, tels que le Retina d’Apple, devraient apprécier. Pour l’exploiter, il vous faudra utiliser une version Git de _xf86-video-intel_ et l’architecture [SNA](http://en.wikipedia.org/wiki/SNA_%28computer_graphics%29 "Sandybridge’s New Acceleration"). Une première version de la gestion du _Connected Standby_ (alias [_InstaGo_](https://en.wikipedia.org/wiki/InstantGo)) est maintenant disponible. Celle‐ci est équivalente à une mise en veille de la machine, mais les applications peuvent réveiller la machine sans intervention de l’utilisateur. Sous Windows, cette fonctionnalité désactive la possibilité de faire une mise en veille en mémoire ou sur le disque et nécessite à la fois un micro‐logiciel UEFI et une carte réseau compatibles. Les pré‐requis pour Linux ne sont pas encore connus. Le pilote _i915_ a maintenant plus de chance de survivre à une situation où il manquerait de mémoire. Dans le cas où il survivrait, plus d’informations seront disponibles pour diagnostiquer la raison. Une gestion préliminaire de la 3D pour les nouveaux systèmes mono‐puces Atom _Cherryview_, qui devrait sortir en septembre 2014, a été ajoutée. Son unité de rendu est basée sur les processeurs _Broadwell_ (sortie prévue fin 2014), alors que le bloc d’affichage est une version améliorée de celui de la génération précédente, _Valleyview_. [Mesa 3D](http://fr.wikipedia.org/wiki/Mesa_%28OpenGL%29) a déjà été [modifié](http://cgit.freedesktop.org/mesa/mesa/commit/?id=9b6b084eb7b10d006b44e3cd22585fc3e39e0c00&utm_source=anzwix) afin de gérer ces nouveaux systèmes mono‐puces. En parlant de _Valleyview_, celui‐ci a reçu beaucoup d’attention pour corriger de multiples bogues. Cependant, l’amélioration la plus importante est la gestion des écrans MIPI DSI. Cela permettra de faire fonctionner l’[Asus _T100_](https://www.asus.com/fr/Notebooks_Ultrabooks/ASUS_Transformer_Book_T100/) correctement, sans bidouille ! Les processeurs de la famille _Broadwell_ gèrent maintenant l’eDRAM, qui sert à fournir 128 Mio de cache de niveau 4 pour les processeurs Iris Graphics basés sur _Broadwell_, la [technologie _boost_](http://www.intel.fr/content/www/fr/fr/architecture-and-technology/turbo-boost/turbo-boost-technology.html), ainsi que le décodage vidéo matériel grâce au moteur VEBOX2. Comme à son habitude, Daniel Vetter (mainteneur _i915_) a publié un [compte rendu des modifications](http://blog.ffwll.ch/2014/06/neat-drmi915-stuff-for-316.html) sur son _blog_, que vous pouvez lire pour plus d’informations. Vous pouvez aussi consulter la [demande d’intégration _i915_](http://comments.gmane.org/gmane.comp.video.dri.devel/107278). ### NVIDIA (pilote nouveau) La nouveauté principale de _Nouveau_ dans cette version est la [réécriture de la gestion du DisplayPort](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b), ce qui a permis de corriger énormément de bogues et permet enfin aux moniteurs de se mettre en veille et de pouvoir en sortir. Le changement de fréquence manuel est maintenant activé par défaut pour les cartes des [familles](https://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units) NV40 (GeForce 7), NVAA/NVAC (ION) et NVE0 (Kepler). Cette gestion est expérimentale et est à utiliser à des fins de test uniquement [[_commit_](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=ed05ba72c841d330cef111282d76a5c7881940f5)]. Phoronix a [fait quelques bancs de test](http://www.phoronix.com/scan.php?page=article&item=linux316_nouveau_clocks&num=1) utilisant cette nouvelle capacité. Toutes les cartes n’ont pas réussi à être re‐cadencées à leur vitesse maximale, mais quand elles l’étaient, les performances étaient améliorées la plupart du temps d’un facteur 4, et jusqu’à 5,8 pour OpenArena. Ce n’est cependant pas suffisant pour atteindre la vitesse du pilote propriétaire, puisque sur les puces de la famille Kepler, _Nouveau_ n’atteint à fréquences égales que de [59 %](http://www.phoronix.com/scan.php?page=article&item=nvidia_nouveau_linux316&num=5) à [80 %](http://www.phoronix.com/scan.php?page=article&item=nvidia_nouveau_linux316&num=2) des performances du pilote NVIDIA. La gestion du GK20A (processeur graphique intégré aux Tegra K1 basé sur Kepler) [fait enfin son entrée dans _Nouveau_](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=a4d4bbf130724c9a9a3dff673eb9342f1dbe2392) grâce au travail d’Alexandre Courbot de NVIDIA. Cette gestion est [conditionnelle à l’utilisation des microcodes de NVIDIA](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=b7c852a646b12051e61c4dde4ddaa6c14af9c80b) pour la gestion des contextes graphiques, jusqu’à ce qu’un contributeur fasse le travail de rétro‐ingénierie ou jusqu’à ce que NVIDIA donne le droit à _Nouveau_ de redistribuer le microcode. En l’état actuel, il devrait donc être possible de créer un contexte graphique et faire du rendu dans une texture. Cette texture pourra ensuite être envoyée via _Prime_ ([_dma-buf_](https://www.kernel.org/doc/Documentation/dma-buf-sharing.txt)) au pilote _host1x_ qui gère l’affichage, mais pas avant Linux 3.18. La gestion de la mémoire est actuellement expérimentale et est en train d’être améliorée par Alexandre. Côté espace utilisateur, il vous faudra attendre la sortie de la prochaine version de Mesa 3D qui devrait arriver aux alentours de la conférence des développeurs de X.Org [_XDC 2014_](http://www.x.org/wiki/Events/XDC2014/ "X.Org Developer’s Conference"), qui aura lieu à Bordeaux du 8 au 10 octobre 2014. D’après Alexandre, ce processeur graphique devrait être utilisable dès Linux 3.18. En parlant de microcode de gestion des contextes graphiques, celui du jeu de puces GK208 a été corrigé afin de pouvoir [gérer les unités (_shaders_) de géométrie](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=255b329ca7f0e9b5fa6da3a68bb713684fe10305). Pour finir, les cartes GeForce GTX 780 Ti et Tesla K40 (GK110B) sont maintenant gérées par _Nouveau_ grâce au travail d’un contributeur externe à _Nouveau_. Celui‐ci a également activé le [décodage vidéo matériel sur les puces GK110, GK110B et GK208](http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/gpu/drm/nouveau?id=5edcf1c0600a4a18334b0aa5e4f6cc4de90e8783) [[noms de code](http://nouveau.freedesktop.org/wiki/CodeNames/)]. ### Samsung (pilote exynos) Plusieurs corrections de bogues liés à la gestion de l’horloge et de la synchronisation verticale. Pour une liste plus détaillée des changements, vous pouvez consulter la [demande d’intégration _exynos_](http://www.spinics.net/lists/dri-devel/msg60720.html). Pour continuer sur la gestion des pointeurs utilisateur, Jérôme a proposé de désactiver complètement sa gestion, car [son implémentation actuelle n’était pas sûre](http://thread.gmane.org/gmane.comp.video.dri.devel/108975/focus=109113). Le mainteneur du pilote DRM Intel a approuvé. Espérons que cette gestion sera réécrite dans Linux 3.17 ou désactivée. ### En vrac * **Aspeed (Ast)** : Ajout de la [gestion de l’AST2400](http://www.aspeedtech.com/products.php?fPath=20&rId=376). * **Freescale (ipuv3)** : Le pilote _ipuv3_, pour les processeurs graphiques Freescale _i.MX IPUv3_, quitte la branche _staging_ et intégre la branche `/drivers/gpu/`. Ce pilote ne respecte cependant pas le standard DRM, probablement parce qu’il ne propose pas d’affichage, comme Tegra. * **Tegra (pilotes _host1x_ et _tegra_)** : Ajout de la gestion des curseurs et du HDMI pour les Tegra 124 (K1). * **Panels** : Ajout de la [gestion de plusieurs écrans](http://www.spinics.net/lists/dri-devel/msg61163.html). ## Réseau Le [_TCP Fast Open_](http://lwn.net/Articles/508865/), ajouté dans Linux 3.13 pour l’IPv4, est maintenant disponible pour l’IPv6 [[_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3a19ce0eec32667b835d8dc887002019fc6b3a02)]. Pour mémoire, le _TCP Fast Open_ permet de diminuer le temps de connexion à un service lorsque plusieurs connexions vers celui‐ci sont ouvertes. Avec _TCP Fast Open_, le serveur n’attend plus que le client émette l’acquittement final avant d’envoyer des données à l’utilisateur. D’un point de vue latence, cela permet d’ouvrir la connexion avec un seul aller, au lieu d’un aller, un retour et un nouvel aller. Cela peut être très efficace pour réduire drastiquement le temps des chargements des pages Web lorsque le réseau d’accès à Internet a une grosse latence. Une émulation logicielle du _TCP Segmentation Offload_ (TSO), c’est‐à‐dire du délestage de la segmentation TCP, a été ajoutée au noyau et permet à des systèmes mono‐puces d’augmenter leur débit maximal de 16 % à 54 %, tout en réduisant l’utilisation processeur de 40 % dans un test de performance basé sur HTTP (_commits_ : [1](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79f339125ea316e910220e5f5b4ad30370f4de85) et [2](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3ae8f4e0b98b640aadf410c21185ccb6b5b02351)). En principe, le TSO consiste à envoyer l’ensemble des données à transmettre à la carte réseau et laisser celle‐ci découper les paquets. Cela permet de limiter la consommation processeur sans perdre de performance. AMD a ajouté la gestion d’une nouvelle carte Ethernet permettant d’atteindre 10 Gbit/s. Le pilote de cette carte s’appelle "amd-xgbe" et celle‐ci fera partie du système mono‐puce _Seattle_ (_commits_ : [[1](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1ebe98dcd89c624d08a3712a8a9f1706bf213172)], [[2](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4d874b30b14674284d72f92485e991b984b0b5e1)], [[3](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c5aa9e3b815645e3aad08444c91ca6b237eeea01)] et [[4](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7c123b6a1c5ce1d7900b4ef7bab5f0491e4f674e)]). ## Sécurité ### Liste non exhaustive des vulnérabilités corrigées : * [CVE-2014-0206](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0206) [[correctif 1](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f8567a3845ac05bb28f3c1b478ef752762bd39ef), [correctif 2](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=edfbbf388f293d70bf4b7c0bc38774d05e6f711a)] ; * [CVE-2014-3534](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3534) [[correctif](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dab6cf55f81a6e16b8147aed9a843e1691dcd318)] ; * [CVE-2014-4014](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4014) [[correctif](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=23adbe12ef7d3d4195e80800ab36b37bee28cd03)] ; * [CVE-2014-4171](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4171) [[correctif](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8e205f779d1443a94b5ae81aa359cb535dd3021e)] ; * [CVE-2014-4508](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4508) [[correctif](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=554086d85e71f30abe46fc014fea31929a7c6a8a)]. ### Bit NX et chargement des modules Les zones mémoire utilisées pour stocker le code et les données d’un module sont protégées respectivement en lecture seule (RO) et en non exécution (NX) à l’aide de la technologie du [bit _NX_](http://fr.wikipedia.org/wiki/NX_Bit) présente dans les processeurs x86 modernes. Jusqu’à présent, ces protections étaient mises en place assez tard dans le chargement d’un module par le noyau. Elles sont maintenant activées avant que les arguments passés lors du chargement du module soient analysés, c’est‐à‐dire juste avant la première exécution de code appartenant au module en cours de chargement [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4982223e51e8ea9d09bb33c8323b5ec1877b2b51)]. Cela améliore légèrement la sécurité, en diminuant l’impact d’une erreur dans le code analysant les arguments passés à un module. ### Compilation à la volée des filtres seccomp Les [filtres _seccomp_](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt) peuvent maintenant profiter du compilateur à la volée (_JIT — Just In Time_) qui a été ajouté pour le langage [BPF](http://fr.wikipedia.org/wiki/Filtre_BPF) [[_correctif_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f577cadf7181243d336be9aba40c1bcc02c4c54)]. Ce langage ne servait au départ que pour le filtrage des paquets réseau, mais il a été étendu et est utilisé par plusieurs sous‐systèmes du noyau (voir [_BPF: the universal in‐kernel virtual machine_](http://lwn.net/Articles/599755/) et [_Extending extended BPF_](http://lwn.net/Articles/603983/)). ### IMA et EVM L’utilisation du mode `O_DIRECT` pour accéder aux fichiers contrôlés par une politique IMA — [_Integrity Measurement Architecture_](http://sourceforge.net/p/linux-ima/wiki/Home/#integrity-measurement-architecture-ima) — pouvait provoquer un interblocage. Ce problème n’est pas encore complètement résolu, mais une solution temporaire a été trouvée pour autoriser un administrateur à désactiver dans la politique de sécurité le contrôle d’IMA pour certains fichiers lorsque le mode `O_DIRECT` est utilisé [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f9b2a735bdddf836214b5dca74f6ca7712e5a08c)]. La méthode de calcul des signatures HMAC utilisées par EVM — [Extended Verification Module](http://sourceforge.net/p/linux-ima/wiki/Home/#linux-extended-verification-module-evm) — a été modifiée [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d3b33679481d52ef02311119d4342a9a1f3d84db)] pour permettre plus facilement l’ajout de nouveaux attributs étendus (par exemple ceux de SMACK) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3e38df56e6ef736f3ab516664697b55caa8f3238)]. L’accès à l’attribut étendu qui stocke cette signature est maintenant restreint [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2fb1c9a4f2dbc2f0bd2431c7fa64d0b5483864e4)]. Un bogue pouvant provoquer des « [_kernel oops_](http://en.wikipedia.org/wiki/Linux_kernel_oops) » lorsqu’IMA était utilisé avec [AppArmor](https://fr.wikipedia.org/wiki/AppArmor) a été corrigé [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0430e49b6e7c6b5e076be8fefdee089958c9adad)]. ### LSM #### SELinux Les informations présentes dans les messages d’erreur d’accès [SELinux](https://fr.wikipedia.org/wiki/SELinux "Security-Enhanced Linux") les AVC — _Access Vector Cache_ — ne permettaient pas de savoir si l’accès avait été réellement bloqué ou s’il avait été autorisé parce que le système ou le type était en mode permissif. Un nouvel élément `permissive=` permet d’obtenir cette information [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ca7786a2f916540931d7114d441efa141c99c898)]. Lorsqu’un processus fait appel à `exec()`, le contexte SELinux reste par défaut celui du père, mais il peut être changé si la politique le précise et que le contexte du fichier exécuté correspond (transition de domaine à l’exécution). Une troisième façon de définir le contexte d’exécution SELinux d’un processus à l’avance est d’utiliser l’appel `setexeccon()`. Dans le cas où un programme tentait un `exec()` d’un fichier dans un système de fichiers monté avec l’option `nosuid`, cette transition n’était pas effectuée, mais aucune erreur n’était retournée. Le code d’erreur `-EACCES` est maintenant retourné dans ce cas [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b589d44fad18228f18749360d008d5c8ff3aaf8)]. #### SMACK _Note : Si vous avez du mal à faire la correspondance entre les accès autorisés et les étiquettes SMACK, je vous conseille de vous référer à la [documentation](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/security/Smack.txt)._ Pour rappel, [SMACK](https://fr.wikipedia.org/wiki/SMACK) — _Simplified Mandatory Access Control Kernel_ — stocke les règles de contrôle d’accès aux objets représentés dans l’arborescence du système dans les attributs étendus (dans l’espace de noms `security`). Il n’est pour l’instant pas possible d’utiliser les attributs étendus avec les pseudo‐fichiers décrivant les _cgroups_. Ces pseudo‐fichiers sont donc étiquetés par défaut avec l’étiquette « `*` », ce qui signifie qu’aucun contrôle supplémentaire n’est effectué par SMACK (tous les accès sont autorisés par SMACK). Ce contournement est nécessaire pour faire fonctionner _systemd_ avec SMACK (probablement dans le cadre du projet Tizen) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36ea735b522d09826ae0dac0e540f294436c52f3)]. Certaines opérations effectuées sur des descripteurs de fichiers ouverts en écriture seule peuvent être apparentées à des opérations de lecture. En effet, les appels système `fstat()` et `lseek()`, par exemple, permettent d’obtenir des informations sur l’état du fichier ouvert et peuvent donc être considérés comme des opérations de lecture. SMACK autorisait ces appels système si le descripteur de fichier était ouvert en écriture seule et que les étiquettes SMACK autorisaient l’opération `write()`. Ce comportement pouvait potentiellement mener à la création d’un canal d’information caché qui n’est pas contrôlé par SMACK. Il n’est donc plus possible d’ouvrir un descripteur de fichier en écriture si l’on ne dispose pas aussi des droits SMACK pour l’ouvrir en lecture (on peut par contre ne pas disposer des droits DAC en lecture) [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a6834c0b9114c06106efee8e9f2a11fbbb104567)]. Une modification du même style avait été ajoutée à SMACK dans le noyau 3.13 (_cf._ _Sortie de Linux 3.13_ au paragraphe [_SMACK_](https://linuxfr.org/news/sortie-de-linux-3-13#smack)). Dans le cas précédent, une nouvelle opération avait été ajoutée pour gérer correctement le cas de figure, mais ici les appels système `fstat()` et `lseek()` ne sont pas contrôlés par les [_hooks_](http://fr.wikipedia.org/wiki/Hook_%28informatique%29) [LSM](https://fr.wikipedia.org/wiki/Linux_Security_Modules "Linux Security Modules"), donc ce n’est pas une solution possible actuellement. Pour pouvoir envoyer une information par l’intermédiaire d’une communication inter‐processus ([IPC](https://fr.wikipedia.org/wiki/Communication_inter-processus)), SMACK vérifie que le processus émetteur dispose du droit d’accès SMACK `write` sur le destinataire. Dans le cas des _sockets_ UNIX (_UNIX domain socket_) la vérification est faite uniquement à la connexion et n’était faite que dans un sens (du processus ouvrant le _socket_ vers le processus ayant créé le _socket_, et pas l’inverse). C’est maintenant corrigé [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e70ec5eb090193b03e69d551fa6771a5a217c4)]. Le retrait de l’attribut `SMACK64TRANSMUTE` d’un dossier n’avait pas l’effet désiré. C’est maintenant corrigé [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f59bdfba3e2b0ba5182f23d96101d106f18132ca)]. L’affectation d’une chaîne vide comme valeur à un attribut étendu ne provoque plus de panique du noyau [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9598f4c9e7069aee8639be1e04e8af26b5a77fa2)]. Un utilisateur doit avoir la capacité `CAP_MAC_ADMIN` pour pouvoir enlever les attributs étendus SMACK d’un fichier. Il était possible, par erreur, d’enlever l’attribut étendu `SMACK64MMAP`. C’est maintenant corrigé [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5e9ab593c2da3064136ffa1d7f712d0e957e1958)]. Une entrée `ptrace()` a été ajoutée au pseudo‐système de fichiers permettant de contrôler le comportement de SMACK. Elle permet de régler le niveau de sécurité requis pour pouvoir utiliser l’appel système `ptrace()` [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=668678185247303450e60df14569f94cf5775fea)]. Les vérifications liées à l’appel `ptrace()` ont été regroupées [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5663884caab166f87ab8c68ec7c62b1cce85a400)]. Un bogue inversant la vérification lors d’un appel à `ptrace()` a été corrigé [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=959e6c7f1eee42f14d31755b1134f5615db1d9bc)]. Les vérifications effectuées lors de l’accès au trousseau de clefs stocké dans le noyau ont subi une correction. Elles étaient incorrectes car une clé avec une étiquette « `_` » ne pouvait être lue alors qu’elle aurait dû être accessible par tout le monde [[_correctif_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fffea214abf66a8672cfd6697fae65e743e22f11)]. ## Systèmes de fichiers Le nettoyage et la réorganisation de code sont des points importants sur le long terme. Quelques fichiers concernant les couches en mode bloc de VFS passent ainsi de l’arborescence `fs/` et `mm/` vers le dossier fédérateur `block/`. ### XFS Du côté de chez XFS, Dave Chinner nous apprend que le code a subi [un nettoyage et un peu de réusinage](http://lkml.iu.edu/hypermail/linux/kernel/1406.1/02012.html). ### Btfrs Le plus gros changement dans cette version est la refonte du calcul des quotas que Josef Bacik a effectuée et qui améliore le suivi en mémoire des opérations `extent` en attente. Chris Mason a travaillé de son côté sur l’utilisation de la pile Btrfs, car il est devenu impossible d’effectuer les longs tests de charge avec `slab()`, `lockdep()` et `pagealloc()` en mode debogage, sans faire exploser la pile. Enfin, il y a les habituelles corrections de bogues, le lot d’optimisation et de nettoyage de code. Pour plus de détails, il est possible de consulter [le rapport résumé](http://lkml.iu.edu/hypermail/linux/kernel/1406.1/02366.html). Phoronix nous offre quelques tests de performances ([_ici_](http://www.phoronix.com/scan.php?page=article&item=linux316_btrfs_ssd&num=2) et [_là_](http://www.phoronix.com/scan.php?page=article&item=linux_316_hdd&num=2)), et le bilan est assez simple : il n’y a pas de changements statistiquement notables. ### F2FS [Jaegeuk Kim nous indique](http://lkml.iu.edu/hypermail/linux/kernel/1406.1/00644.html) que Samsung s’affaire toujours à améliorer ce système de fichiers. Il prend en charge des partitions de taille supérieure à 2 Tio correctement, tout en améliorant la gestion du [`readahead`](https://fr.wikipedia.org/wiki/Readahead). Pour rappel, cette lecture anticipée permet de précharger un fichier dans la mémoire vive pour diminuer les temps de latence par la suite. Enfin, le `flush()` des fichiers a été amélioré. ### Reiser4 Ivan Shapovalov [a continué à travailler](http://marc.info/?l=reiserfs-devel&m=140267151617556&w=2) sur l’implémentation du mécanisme de *discard* (mise au rebut), aussi connu sous le nom de TRIM. Celui-ci permet d’informer un SSD que des blocs mémoire sont inutilisés et peuvent être effacés. Ce travail devrait permettre d’améliorer les performances de Reiser4 avec les SSD. ### NFS Neil Brown a corrigé NFS afin que les montages locaux (sur la même machine) fonctionnent correctement [dans tous les cas de figure](http://lwn.net/Articles/595652/). Par ailleurs, la gestion XDR (*eXternal Data Representation*) a été réécrite afin de pouvoir gérer de grosses listes de contrôle d’accès (_Access Control Lists_) faisant plus de 4 Kio. De même, la fonction `readdir()` renvoie aussi des résultats pouvant faire plus de 4 Kio, ce qui améliore les performances pour les dossiers ayant un très grand nombre de fichiers. ##Virtualisation ###[KVM](https://lkml.org/lkml/2014/6/4/121) Plus de 200 _commits_ pour cette version, répartis un peu partout. Commençons avec x86, pour lequel on retrouve la virtualisation imbriquée pour Xen : c’est‐à‐dire qu’il est possible de faire tourner Xen dans une machine KVM tout en permettant la virtualisation matérielle de Xen. C’est une fonctionnalité principalement utile pour les migrations ou les tests. Du côté des processeurs ARM, la publication des informations PSCI (_Power State Coordination Interface_) en version 0.2 est disponible avec les instructions ARMv8. Dans les noyaux précédents, seule la version 0.1 de PSCI était disponible. Ces instructions permettent d’améliorer la gestion de l’énergie, particulièrement quand plusieurs systèmes d’exploitation tournent sur un même système mono‐puce et qu’il faut qu’ils se coordonnent, par exemple pour savoir quand un processeur peut être éteint. Dans le cas des processeurs POWER, la prise en charge de _u-boot_ est disponible pour les systèmes embarqués, pour la version 8, la prise en charge des hôtes configurés en petit‐boutiste ([_Little Endian_](https://fr.wikipedia.org/wiki/Little_endian#Little_endian)). Et enfin, pour le S/390 ([_mainframe_](https://fr.wikipedia.org/wiki/Mainframe "Ordinateur central") IBM), les principaux changements sont la prise en charge des migrations, ainsi que de débogueur GDB. Pour la prochaine version, on attend un gros lot de _commits_ pour le x86, et le retrait de l’architecture [IA-64](http://fr.wikipedia.org/wiki/IA-64) (les [Itanium](https://fr.wikipedia.org/wiki/Itanium)). ###[Xen](https://lkml.org/lkml/2014/6/2/167) Xen sous ARM gère désormais les deux fonctions `suspend()` et `resume()`. Côté réseau, l’interface virtuelle pour gérer le réseau prend désormais en charge le mode multi‐queue, ce qui améliore les performances réseau des machines virtuelles. # Le bilan en chiffres En ce qui concerne les statistiques du cycle de développement de Linux 3.16, on peut se référer à la [page dédiée du site _remword.com_](http://www.remword.com/kps_result/) qui compile des statistiques relatives au développement de Linux. Le nombre final de correctifs incorporés dans cette version est de 12 802, soit légèrement en dessous des 13 720 correctifs de la précédente. Ces ajouts sont le résultat du travail d’environ 1 527 développeurs soit, là encore, une légère baisse par rapport aux 1 547 développeurs du noyau précédent. C’est à nouveau Intel qui occupe la tête du classement des entreprises avec 10,52 % des correctifs, suivi de très près par Red Hat (10,37 %). Red Hat est, en revanche, l’entreprise qui signe le plus de correctifs, avec 11,85 % contre 10,25 % pour Intel. Les hobbyistes occupent comme d’habitude la troisième place, avec 5,73 %, si l’on ne comptabilise pas les contributeurs dont l’affiliation est inconnue, qui représentent 18,01 % des contributions. Le développement de Linux est donc majoritairement sponsorisé par des entreprises, mais il reste encore de nombreux passionnés qui font ça pour eux. # Appel à volontaires *Jiehong*, le mainteneur actuel de la partie *Systèmes de fichiers* va laisser sa place à une personne ayant plus de temps. Cette position est maintenant ouverte. Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition : | Mainteneur | Contributeur(s) ----------------------------- | -------------------------------------------------- | --------------- **La phase de test** | Aucun |[Mali](https://linuxfr.org/users/mali), [Julien Pecqueur](https://linuxfr.org/users/jpec) **Architectures** | [Romain Perier](https://linuxfr.org/users/rperier) |[Mali](https://linuxfr.org/users/mali), [Timothée Ravier](https://linuxfr.org/users/siosm) **Pilotes graphiques libres** | [Martin Peres](https://linuxfr.org/users/mupuf) | **Réseau** | [Florent F.](https://linuxfr.org/users/ffourcot) | [Martin Peres](https://linuxfr.org/users/mupuf) **Systèmes de fichiers** | [Jiehong](https://linuxfr.org/users/jiehong) |[Mali](https://linuxfr.org/users/mali), [Julien Pecqueur](https://linuxfr.org/users/jpec) **Sécurité** | [Timothée Ravier](https://linuxfr.org/users/siosm) | **Virtualisation** | [Xavier Claude](https://linuxfr.org/users/claudex) | **Édition générale** | Aucun | [Martin Peres](https://linuxfr.org/users/mupuf), [Davy Defaud](https://linuxfr.org/users/davy78) Un peu de vocabulaire : * le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ; * un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur. 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 tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les _commits_ intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !

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