URL: https://linuxfr.org/news/sortie-de-linux-3-14 Title: Sortie de Linux 3.14 Authors: Martin Peres Davy Defaud, Siosm, Jarvis, Romain Perier, BAud, Sidonie_Tardieu, Thomas Debesse, Mali, maboiteaspam, yogitetradim, claudex, Florent Fourcot, jcr83, palm123, ZeroHeure, Benoît Sibaud, patrick_g, Kioob, JPEC, tuiu pol, yalla, Karmak23, Maxime, Dreamkey, Bruno Michel et reynum Date: 2014年01月20日T22:45:19+01:00 License: CC By-SA Tags: linux, radeon, kernel, noyau_linux, coulisses, linus_torvalds et fosdem Score: 110 La sortie de la version stable 3.14 du noyau Linux [vient d’être annoncée](http://lkml.iu.edu/hypermail/linux/kernel/1403.3/03023.html) par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site _kernel.org_. Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. Bon, ça c’est fait ! ![Pi](http://upload.wikimedia.org/wikipedia/commons/thumb/2/2e/Pi-symbol.svg/200px-Pi-symbol.svg.png) Mais Linus vous réserve bien d’autres nouveautés... :) ---- [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.14) [Phoronix: Recapping The Top Changes Of The Linux 3.14 Kernel](http://www.phoronix.com/scan.php?page=news_item&px=MTYzNDg) ---- # La phase de test ##RC-1 La version RC-1 est sortie le [2 février 2014](http://lkml.iu.edu/hypermail/linux/kernel/1402.0/00359.html).> Eh, c’était une fenêtre ordinaire de fusion sur quinze jours, qui est maintenant terminée. Autant que je sache, j’ai intégré tout ce qui m’a été demandé (à une exception près, voir plus loin) et j’ai appliqué tous les correctifs que je devais appliquer. Si vous pensez que j’ai oublié votre travail, cela pourrait être à cause d’un courriel pris pour un pourriel (cela est arrivé plusieurs fois récemment, mais je pense que je les ai tous) ou d’une simple incompétence de ma part (cela arrive aussi).> > J’ai conscience que le nombre 3,14 semble familier pour certains, et j’ai eu des demandes de nommage en rapport avec cela. Mais ce n’est tout simplement pas comme cela que fonctionne le nommage du noyau. Vous pouvez vous consoler avec le fait que le nom ne s’affiche pas partout, et que personne n’y porte un réel intérêt. Ainsi, n’importe quel nom en lien avec π que vous pourriez concevoir, serait tout aussi pertinent que celui dans le _Makefile_ principal, donc ne soyez pas déprimé.> > Par ailleurs, n’importe quel _geek_ qui se respecte connait vingt décimales de π depuis qu’il est un jeune con. Donc, 3,14 n’est vraiment pas si proche, n’est‐ce pas ?>> Qu’importe, la demande d’intégration manquante est l’appel système _rename2()_ que je pensais devoir regarder par moi‐même, et pour laquelle j’espérais aussi plus de commentaires (je suis en train de te regarder, [Al](http://heretic.net-ronin.org/~ramune/humor/viro/)). Bref, j’ai senti que je n’avais pas le débit mental suffisant pour m’en occuper pendant cette fenêtre de fusion, mais je prendrai le temps de regarder ça tranquillement cette semaine. Je pourrais toujours l’intégrer avec la RC-2, mais franchement, c’est plus que probable que ça attende la 3.15.>> Autre chose ? Le truc que j’ai vraiment fusionné ? C’était une fenêtre de fusion ordinaire, rien ne sort du lot. Les statistiques font apparaître le très traditionnel deux tiers pour les pilotes, le reste concernant un mélange de mises à jour des architectures (ARM domine, mais il y a du PowerPC, X86, MIPS, s390, et même du IA-64 avec de la suppression de code obsolète dans Xen) et du tout‐venant : cœur du noyau, gm (NDT : gestion de la mémoire), réseau, outillage, etc.>> J’ai joint mon journal de fusion, vu que comme d’habitude la version courte du journal est bien trop longue. Et, encore une fois, notez que mon journal de fusion ne donne que les noms des mainteneurs, pas les noms de ceux qui ont effectivement codé. Il faut lire les journaux complets de Git pour avoir ce niveau de détail.>> Linus ![Al Viro](http://www.abclinuxu.cz/images/screenshots/5/6/102065-alexander-viro-17374.jpg) ##RC-2 La version RC-2 est sortie le [9 février 2014](http://lkml.indiana.edu/hypermail/linux/kernel/1402.1/00660.html).> Ça a été plutôt calme, en fait, ce qui devrait me rendre heureux. Mais je suis de nature méfiante, et je vais attendre de voir si la situation empire et si les gens sont juste en train de me bercer d’un faux sentiment de sécurité. Parce que je connais les développeurs du noyau, et ils sont sournois. Je soupçonne que [Davem](http://en.wikipedia.org/wiki/David_S._Miller) (pour prendre quelqu’un, pas au hasard) est en train de rire nerveusement, attendant ce message, planifiant de m’envoyer demain des demandes d’intégration de gros porc.> > Parce que les gars, vous êtes de ce genre‐là.>> Qu’importe, le peu de nouveautés semble normal : à peu près deux tiers de pilotes (pilotes graphiques, pilotes en mode bloc, média et divers), avec presque la moitié des correctifs restants pour la mise à jour des architectures (x86, s390 et ARM64). Le reste concerne les systèmes de fichiers (VFS, NFS, OCFS, Btrfs et quelques corrections de kernfs), quelques trucs sur la gestion de la mémoire et de l’outillage (performance).>> La version courte du journal est jointe, ce qui n’arrive pas à chaque RC2.>> Linus ![Davem](http://upload.wikimedia.org/wikipedia/commons/0/0c/DaveMiller.jpg) ##RC-3 La version RC-3 est sortie le [16 février 2014](http://lkml.iu.edu/hypermail/linux/kernel/1402.2/00118.html).>Quand j’ai annoncé la RC-2, j’ai mentionné combien elle était plaisante et petite. J’ai également noté que je ne vous faisais pas confiance et que je soupçonnais que certains d’entre vous gloussaient dans leur coin en retardant leurs demandes d’intégration, diaboliques petites créatures que vous êtes.>> Et je déteste avoir raison. La RC-2 était assez légère, mais la RC-3 la contrebalance. J’ai tranquillement pris toutes les demandes d’intégration parce que cela n’était clairement pas une surprise, mais je vous avertis que je vais commencer à maudire des gens, si cette tendance se maintenait. Vous avez été prévenus.>>Quoi qu’il en soit, parce que la version courte du journal est assez lourde, je présente les grandes lignes de mon journal de fusion ici, et je posterai sa version courte séparément en réponse à ce courriel, pour ceux qui veulent plus de détails. L’essentiel des modifications concerne le réseau et divers pilotes (réseau, de la branche _staging_, USB, pilote en mode bloc, InfiniBand...), mais il y a quelques mises à jour d’architecture (PowerPC, ARM, x86) et quelques mises à jour de la documentation.>>Linus ##RC-4 La version RC4 est sortie le [23 février 2014](http://lkml.iu.edu/hypermail/linux/kernel/1402.2/05133.html).> Bon, tout semble normal, et la RC-4 est plus légère que la RC-3, je suis donc heureux.>> Le plus gros changement inclus (représentant environ un sixième de la taille) est seulement dû à la ré‐indentation d’un fichier ReiserFS effectuée par [DaveJ](http://codemonkey.org.uk/). En ignorant ce nettoyage d’espaces, il ne reste que le lot habituel de mises à jour de pilotes, des couches réseau et de quelques architectures.>> Rien d’énorme, ni de particulièrement effrayant.>> Alors prenez‐la, et testez‐la complètement.>> Linus ![DaveJ](http://davej.fedorapeople.org/davej.png) ## RC-5 La version RC5 est sortie le [2 mars 2014](http://lkml.iu.edu//hypermail/linux/kernel/1403.0/00421.html).> Une autre semaine, une autre RC.>> Les choses ont été tout à fait calmes, et tout à fait normales. Les pilotes représentent un peu moins de 60 % des changements (le son est prédominant du fait de deux changements qui sont plus importants mais triviaux, mais il y a divers changements ponctuels partout). Le reste vient pour la plupart des mises à jour d’architectures (principalement PowerPC et Xtensa), et puis il y a une poignée de petites choses ailleurs.>> Pas beaucoup. C’est exactement ce que j’aime.>> Allez vérifier que tout fonctionne pour vous.>> Linus ## RC-6 La version RC6 est sortie le [10 mars 2014](http://lkml.iu.edu/hypermail/linux/kernel/1403.1/00505.html).>Nous nous approchons de la fin du cycle de RC et je dois admettre que j’aurais préféré un parcours moins chaotique.>>Il n’y a pas eu d’énormes problèmes, mais il y a eu pas mal de petits heurts qui n’auraient jamais dû arriver si tard dans le cycle de sortie. Et la RC-6 est également sensiblement plus grosse que ne l’était la RC-5.>> Donc, j’espère réellement que la semaine à venir sera plus calme, car sinon je devrai faire une RC-8 voire une RC-9...>>Cela dit, il n’y a rien de fondamentalement inquiétant jusqu’ici. De petites erreurs idiotes et quelques malheureux _retours arrières_ tardifs de _commits_, mais le gros reste des corrections triviales. Donc, je reste raisonnablement optimiste.>>Linus ## RC-7 La version RC7 est sortie le [16 mars 2014](http://lkml.iu.edu/hypermail/linux/kernel/1403.2/00164.html).> Une semaine peut vraiment faire la différence. En mieux. Il y a une semaine, en récoltant la RC-6, j’étais mécontent : il y avait trop de correctifs épars et j’augurais une RC-8, voire une RC-9, comme une réelle éventualité.>> Mais maintenant, une semaine s’est écoulée, et la RC-7 semble beaucoup plus satisfaisante. Bon, il y a encore des choses imprévisibles un peu partout (les plus grosses contributions concernent le réseau, à la fois dans le cœur et les pilotes), mais c’est beaucoup plus petit que pour la RC-6, et il n’y a rien qui m’incommode. Quasiment tous les changements sont petits, et je pense que le changement qui retire la vieille et inutile option `x86 Centaur OOSTORE` est probablement le plus gros d’entre eux. Le seul autre changement qui pourrait rivaliser en taille supprime du code lui aussi (« r8152 : désactiver le mode ECM »).>> Maintenant, les choses peuvent encore changer, et peut‐être que la prochaine semaine se terminera comme une semaine horrible, mais avec un peu de chance cela n’arrivera pas et c’est la dernière RC.>> Allez-y, testez. Tout ça a l’air bon.>> Linus ## RC-8 La version RC8 est sortie le [24 mars 2014](http://lkml.iu.edu/hypermail/linux/kernel/1403.3/00475.html).> J’avais pris un délai d’un jour sur mon calendrier habituel, espérant être plus à l’aise pour sortir cette version 3.14, mais cela n’a pas été le cas. Donc, voici une RC-8, et j’espère faire la dernière version le week‐end prochain.>> Il n’y avait pas tant de choses effrayantes en cours, mais il y a quelques correctifs VFS en attente, et nous avons fini par avoir quelques correctifs intéressants sur le code principal la semaine dernière (pas de nouvelles régressions, sauf celles récemment découvertes par [Trinity](http://codemonkey.org.uk/projects/trinity/). Félicitations à Hug Dickins pour les avoir comprises et en avoir corrigé les causes). Il y a aussi quelques correctifs réseau et des correctifs épars (principalement MIPS). Je souhaitais vraiment, par conséquent, une autre semaine avant de tout livrer.>> Linus ## Version finale La version finale est sortie le [30 mars 2014](http://lkml.iu.edu/hypermail/linux/kernel/1403.3/03023.html).> Bon, nous avons eu quelques changements tardifs dont j’aurais pu me passer, mais la liste des changements depuis la RC-8 est assez petite, et je le sens bien tout ça. Si nous avions rencontré quelques problèmes de dernière minute à cause du sursaut de contribution final, ces corrictifs seraient très spécifiques et je n’ai donc pas vraiment de raison de retarder la publication sans rien avoir en suspens. La majorité de ce sursaut final concerne des régressions marquées comme candidates pour les branches stables ou pour des régressions connues.>> Donc, la 3.14 est là et la fenêtre d’incorporation pour la 3.15 est ouverte. Veuillez, s’il vous plaît, prendre le temps de tester cette 3.14, même si vous êtes pressés de me faire parvenir votre file d’attente pour la prochaine version.> > Linus # Les nouveautés ## Arch ### CPU #### Multi‐processeurs Xtensa Le processeur Xtensa reçoit la gestion multi‐processeurs [SMP](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b83d851a2bdd021e2135999e5bce3eb8fef94e6) (_Symetric Multi‐Processors_). Xtensa est le processeur configurable et extensible de Tensilica, racheté en 2013 par Cadence Design Systems, basé sur une architecture 32 bits de type [RISC] (http://fr.wikipedia.org/wiki/Reduced_instruction_set_computer). Connu pour sa grande personnalisation et sa modularité, il permet par exemple de choisir le « [boutisme](http://fr.wikipedia.org/wiki/Boutisme) », la largeur du bus de données, l’ajout d’unités de calcul en virgule flottante supplémentaires, etc. #### Co‐processeurs cryptographiques AMD [L’AMD CCP (_Cryptographic Coprocessor_)](http://www.phoronix.com/scan.php?page=news_item&px=MTU4MTM) est maintenant pris en charge par Linux 3.14. Un co‐processeur est un circuit intégré couplé au processeur central qui permet de lui ajouter un support matériel dédié pour une tâche donnée (il en existe plein, comme par exemple des co‐processeurs arithmétiques ou vectoriels). Selon les sources, ce CCP pourrait être embarqué dans le ARM cortex-A15 de leur futur système monopuce Opteron. Il permettrait en outre de gérer les algorithmes de chiffrement AES, AES-CMAC, XTS-AES et les fonctions de hachage SHA directement en matériel. #### MIPS interAptiv et proAptiv L’équipe [MIPS](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cdfc83075fb76369a31e6c187d0cebcab9f8b9c8) nous propose la gestion des derniers processeurs de la marque, à savoir le MIPS interAptiv et le proAtiv. MIPS fabrique principalement ses puces pour des appareils grand public, comme, par exemple, des lecteurs Blu‐ray de salons ou des télévisions numériques. On les retrouve également dans des terminaux bas de gamme de certains pays émergents. L’interAptiv est la dernière génération de processeur à basse consommation multi‐cœur de MIPS. Il est doté de la technologie MIPS _Multi‐Threading_ (MT), proche de la technologie _hyper‐threading_ d’Intel. Le MT est une technologie employée dans les processeurs multi‐cœurs ces dernières années, afin que la topologie et la réalisation matérielle soit plus adaptées aux programmes disposant de plusieurs fils d’exécution, chose très répandue de nos jours. Cette technologie permet d’obtenir de meilleures performances pour les programmes qui sont correctement prévus à cet effet (ce qui n’est pas toujours le cas et peut entraîner des surprises, comme de la contention sur l’utilisation des unités de calcul partagées ou une mauvaise utilisation du cache). Ce processeur dispose également d’un protocole de cohérence de cache censé réduire et limiter les temps d’accès. Le proAptic est le dernier processeur visant à concurrencer la société ARM sur la téléphonie mobile, les tablettes et peut‐être les télévisions connectées. Le constructeur annonce un noyau deux fois plus petit que l’ARM Cortex-A15, avec des performances similaires, voire plus élevées. Encore faut‐il que la performance soit au rendez‐vous... #### ARM64 : gestion de l’allocateur mémoire CMA Dans les ordinateurs de bureau contemporains les contrôleurs [DMA](http://en.wikipedia.org/wiki/Direct_memory_access) (_Direct Memory Access_) doivent avoir accès à la mémoire principale afin de pouvoir y copier ou y lire de grosses quantités de données (requête préalablement demandée par le noyau). Ces derniers n’ont pas directement accès à la mémoire physique pour diverses raisons : les périphériques peuvent être bogués et corrompre la totalité de la mémoire du système, ou nécessiter de gros tampons de mémoire contiguë (ce qui n’est pas toujours possible dans la mémoire physique), etc. Le lien entre la mémoire principale et ces périphériques est réalisé par le biais d’une [IOMMU](http://en.wikipedia.org/wiki/IOMMU). Il s’agit d’une unité de gestion de la mémoire comme la [MMU](http://en.wikipedia.org/wiki/Memory_management_unit) qui permet de faire correspondre une adresse virtuelle à une adresse physique, uniquement pour celles qui ont été enregistrées par le noyau. De nos jours, les cartes embarquées étant de plus en plus petites, et pour certaines de moins en moins coûteuses, il est assez rare qu’elles soient munies d’IOMMU. Oui, mais, comment gérer l’obtention de tampons contigus dans la mémoire physique ? Doit‐on maintenir cette correspondance directement dans nos modules ? C’est la raison pour laquelle l’infrastructure [CMA](https://lwn.net/Articles/396657/) (_Contiguous Memory Allocator_) a été ajoutée au noyau il y a quelques années. Il s’agit d’une boîte à outils qui permet de demander l’allocation de zones mémoire contiguës directement dans la mémoire physique (quand c’est possible) ou de respecter certaines conditions d’alignement, par exemple. Les processeurs ARM 64 bits ont maintenant la possibilité d’utiliser cet allocateur mémoire. #### Intel Merrifield Le Merrifield, la dernière née des puces 64 bits mobile d’Intel annoncée à la _Mobile World Congress 2014_, est maintenant [géré dans le noyau](http://lkml.iu.edu//hypermail/linux/kernel/1401.2/01911.html). Comparé à la génération précédente, le Merrifield apporte de meilleures performances graphiques 2D, une fréquence d’horloge un peu plus élevée (6,5 %), il gère jusqu’à 4 Gio de mémoire vive LPDDR cadencée à 533 MHz et intégrera le processeur graphique Power VR _Series 6_. ### Nouvelles plates‐formes ARM De nouvelles plates‐formes à base de processeurs ARM font leur apparition : - HiSilicon intègre la gestion de sa première carte. Il s’agit d’un constructeur chinois créé par Huawei destiné à produire des systèmes monopuces (_System on Chip_) ARM. - Les plates‐formes embarquées EFM32 ARMv7-M sont gérées. EFM32 est une famille de microcontrôleurs basés sur ARM 32 bits et construits par Silicon Labs. Ces microcontrôleurs sont destinés à des solutions à très basse consommation énergétique. Ces principales caractéristiques sont : des temps de calcul très faibles, un temps de réveil (lors d’interruptions) très rapide et une très faible consommation. - Le Marvell _Berlin_, la puce à l’intérieur de la Google _Chromecast_, dispose d’une prise en charge officielle. - La plate‐forme industrielle Moxa ARM est gérée dans cette version 3.14. - Le Freescale _i.MX50_ est officiellement géré. ### Allocateurs mémoire et classes d’allocations #### ARM : protection des classes d’allocations des modules Les plates‐formes disposant d’un processeur ARM peuvent configurer le noyau afin que les classes d’allocations des modules disposent de droits différents. Les classes d’allocations sont des zones mémoires disjointes dans lesquelles les données et le code sont disposés par le système au moment du chargement d’un programme ou d’un module. L’idée principale est de séparer les données entre elles en fonction de l’utilisation dont va en faire l’entité logicielle concernée, mais aussi de séparer le code de celle‐ci. Ceci est fait à la fois pour respecter une sémantique d’utilisation, mais aussi pour des raisons de sécurité. Il serait en effet regrettable de pouvoir exécuter une zone de données, comme le tas ou la pile (exploitable en cas de dépassement de tampons, par exemple) ou de pouvoir modifier la zone mémoire dans laquelle se trouve le code. À partir de la version 3.14, les plates‐formes ARM pourront demander au système que les zones de code des modules, ou celles censées être en lecture seule, ne soient pas modifiables. Elles auront également la possibilité de restreindre l’exécution de certaines classes d’allocations. ### Ordonnancement La classe d’ordonnancement `SCHED_DEADLINE` est l’une des grandes nouveautés de cette version. Il s’agit d’une politique d’ordonnancement temps réel basée sur l’algorithme _Earliest deadline first_ ([EDF](http://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling)) — la prochaine échéance en premier. Les processus doivent fournir trois paramètres à l’ordonnanceur : une limite temporelle au‐delà de laquelle il ne faut pas aller pour que la tâche soit accomplie, une période spécifiant la fréquence à laquelle elle doit être exécutée et un temps processeur maximum à ne pas dépasser lors de l’exécution de cette tâche (sa durée maximale). Les processus sont ensuite placés dans une file de priorité, ainsi, à chaque fois que l’ordonnanceur reprend la main (préemption ou coopération en rendant la main à ce dernier lors d’une action bloquante, par exemple), il exécute la tâche dont la limite d’exécution est la plus proche. Les ordonnanceurs _deadline_ sont très utiles pour les tâches en temps réel ou pour les tâches périodiques multimédias. ### Développement, déboguage et outils #### perf L’une des grandes nouveautés de `perf` est l’ajout de la prise en charge du compteur de consommation énergétique d’Intel, RAPL. RAPL (_Running Average Power Limit_) est une fonctionnalité matérielle introduite lors de la sortie des processeurs de la famille _Sandy Bridge_ qui permet de surveiller, contrôler et collecter des informations concernant la consommation énergétique des systèmes monopuces (_System on Chip_) d’un ordinateur. Les développeurs du noyau pourront donc savoir précisément quels sont les composants matériels les plus sollicités énergétiquement en fonction des modifications qu’ils effectueront. Plus d’informations sur RAPL sont disponibles dans la [dépêche de sortie de Linux 3.13](https://linuxfr.org/news/sortie-de-linux-3-13#power--acpi). L’utilitaire en espace utilisateur bénéficie également de nombreuses améliorations et nouvelles fonctionnalités. Pour plus de détails, veuillez consulter la requête de fusion d’[Ingo Molnar](http://git.kernel.org/linus/9326657abe1a83ed4b4f396b923ca1217fd50cba). 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. #### kexec `kexec` est désormais compatible avec les systèmes disposant d’[EFI](http://lkml.indiana.edu/hypermail/linux/kernel/1401.2/01909.html). Actuellement, ceci n’était fonctionnel qu’à partir d’un BIOS. L’architecture [[M68k]] bénéficie également d’une prise en charge préliminaire de `kexec`. `kexec` (_kernel execution_) est une fonctionnalité au sein de Linux qui permet de démarrer à chaud un nouveau noyau en écrasant l’espace d’adressage du noyau en cours d’exécution. Cette procédure permet d’éviter les phases d’initialisation matérielle faites par le micro‐logiciel BIOS ou UEFI, ainsi que le chargeur de démarrage, réalisées au lancement de votre ordinateur. Ceci permet donc de gagner un temps considérable lorsque vous souhaitez mettre à jour votre noyau ou lorsqu’un développeur réalise des changements dans un composant central du noyau qui nécessitent un redémarrage. #### smp_load_acquire() et smp_store_release() Les barrières de synchronisation mémoire _smp_load_acquire()_ et _smp_store_release()_ ont été ajoutées. Voir [cet article](http://lwn.net/Articles/576486/) de LWN pour savoir quand elles sont nécessaires et comment les utiliser. #### preempt_enable_no_resched() _preempt_enable_no_resched()_ est une fonction qui permet de réactiver le mode préemptif de l’ordonnanceur du noyau, préalablement désactivé, tout en demandant à ce dernier de ne pas interrompre la tâche courante immédiatement. Cette fonction n’est plus disponible pour les modules, car elle est jugée trop dangereuse et mal utilisée par les développeurs de l’ordonnanceur du noyau qui considèrent que les modules ne devraient pas faire preuve de créativité à ce niveau‐là. Pour plus d’informations, veuillez consulter [ce fil de discussion](http://lkml.iu.edu//hypermail/linux/kernel/1311.2/02075.html). ## Pilotes graphiques libres ### DRM (Direct Rendering Manager) Peu de nouveautés pour DRM, si ce n’est une amélioration de la gestion des hotodatages et un peu de nettoyage de code. Voir la [demande d’intégration](https://lkml.org/lkml/2014/1/29/499). #### TTM (allocateur mémoire graphique) La principale nouveauté de TTM devait être une augmentation des performances processeur lors de l’allocation de pages mémoire partagées, grâce à l’utilisation du drapeau `VM_PFNMAP` au lieu de `VM_MIXEDMAP` ([commit](http://lists.freedesktop.org/archives/dri-devel/2013-November/049338.html)). Cependant, durant le cycle des RC, un problème de performance a été trouvé dans certains cas (utilisation combinée de `VM_PFNMAP`, [x86 PAT](http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/Documentation/x86/pat.txt) et du _[[en:write-combining]]_). Le correctif initial a donc été enlevé en attendant de mieux investiguer le problème ([_commit_](http://lists.freedesktop.org/archives/dri-devel/2014-March/055479.html)). TTM se voit aussi recevoir une amélioration liée au partage de tampons graphiques entre différentes cartes graphiques (DMA-buf). TTM ne générera plus de fautes de page sur les pages importées par DMA-buf ([_commit_](http://lists.freedesktop.org/archives/dri-devel/2014-January/051199.html)). Voir la [demande d’intégration](http://lists.freedesktop.org/archives/dri-devel/2014-January/051813.html). ### Adreno (pilote msm) La principale nouveauté du pilote graphique _msm_ est la prise en charge des Adreno 330. Cette prise en charge a nécessité de retravailler l’architecture du pilote du bloc d’affichage qui est passé de sa version 4 à 5. Comme ces blocs sont similaires, du code a été factorisé. Le pilote _msm_ peut maintenant fonctionner sur des systèmes ne disposant pas d’[IOMMU](https://en.wikipedia.org/wiki/IOMMU). Dans ces cas‐là, le pilote réservera dans la mémoire centrale une zone qui sera dédiée aux rendus graphiques grâce au [_Contiguous Memory Allocator_](https://lwn.net/Articles/396657/) (CMA). La taille de cette zone mémoire est configurable grâce au paramètre noyau ``msm.vram``. Pour des raisons de sécurité, le pilote refuse encore de se charger si aucune MMU n’est disponible, afin d’empêcher le processeur graphique d’accéder aux adresses qui ne lui sont pas réservées. Il semblerait que cette restriction puisse être levée dans le futur car le processeur graphique aurait un moyen matériel de limiter les adresses auxquelles les clients graphiques peuvent accéder. La gestion de [`COMPILE_TEST`](http://cateee.net/lkddb/web-lkddb/COMPILE_TEST.html) fait également son entrée. Cette gestion permet de forcer la compilation du pilote, même quand on n’est pas sur une architecture gérée par _msm_. Cela permet de tester la compilation depuis une autre plate‐forme. Pour finir, les systèmes monopuces APQ8060A (processeur double cœur + processeur graphique Adreno 320) sont désormais pris en charge. Voir la [demande d’intégration](http://www.spinics.net/lists/dri-devel/msg51396.html). ### AMD/ATI (pilote radeon) La prise en charge du DPM (_Dynamic Power Management_) a été ajoutée pour la famille de carte _Sea Islands / CIK_, ce qui devrait permettre de réduire la consommation énergétique et la température sur les cartes qui l’embarquent. Toujours dans la famille _Sea Islands_, la prise en charge de l’UVD (décodage vidéo matériel) a été de nouveau ajoutée. Il semblerait que sa prise en charge ait été accidentellement supprimée il y a un an, lors de la fusion de la gestion de l’UVD dans le noyau ([_commit_](http://www.spinics.net/lists/stable/msg32559.html)). Dans la famille _Volcanic Islands_, la puce _Hawaii_ vient de recevoir des microcodes, ce qui devrait permettre d’activer l’accélération 2D, 3D et vidéo. Une [modification tardive](http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=7c4c62a04a2a80e3feb5d6c97aca1e413b11c790) sur la partie gérant l’envoi de commandes a permis d’activer la prise charge des _geometry shaders_ (GS) sur les cartes des _r600_ et _r700_. Cela permet donc à _radeon_ d’assurer une prise charge d’OpenGL 3.2 et 3.3 sur ces cartes ! Rashika Kheria, du Programme de sensibilisation pour les femmes (_Outreach Program for Women_), a également écrit plusieurs correctifs pour résoudre des alertes dans le pilote, afin de pouvoir activer un niveau de débogage plus élevé dans GCC lors de la compilation du noyau ([plus d’informations](https://plus.google.com/116960357493251979546/posts/CRw4owgvc1W)). Le pilote a également reçu plusieurs corrections de bogues et légères améliorations. Voir la [demande d’intégration](http://www.spinics.net/lists/dri-devel/msg51310.html) pour plus d’informations. ### Intel (pilote i915) La gestion des processeurs graphiques _Broadwell_ est maintenant considérée comme stable et ne nécessitera plus d’options de compilation particulières. La gestion des processeurs _Baytrail_ s’est aussi améliorée, notamment sur l’affichage (branchement à chaud du VGA). La deuxième grande nouveauté est que la gestion des modes d’affichage en espace utilisateur (_User‐space Mode-Setting_ — UMS) est maintenant dépréciée en faveur de gestion des modes d’affichage par le noyau (_Kernel‐based Mode-Setting_ — KMS). Le pilote Intel était le dernier à gérer officiellement l’UMS depuis que le pilote Radeon [a décidé de déprécier sa gestion](http://www.phoronix.com/scan.php?page=news_item&px=MTI2ODA) en janvier 2013. La prise en charge de l’UMS devrait être définitivement [retirée dans le noyau 3.16](http://www.phoronix.com/scan.php?page=news_item&px=MTY0OTA). Dans la même veine de suppression des vieilles interfaces, il est maintenant possible de compiler le pilote _i915_ sans prise en charge de _fbdev_. Ce n’est pas une bonne idée pour la plupart des utilisateurs de bureau, car certaines applications telles que l’écran de chargement Plymouth en dépendent. En revanche, cela permet à certaines plates‐formes embarquées de réduire le volume de code compilé. Dans le futur, nous pouvons penser qu’il sera possible d’utiliser des applications telles que [_kmscon_](http://www.freedesktop.org/wiki/Software/kmscon/), de façon à rendre totalement obsolète l’interface _fbdev_. Côté sécurité, la gestion du PPGTT (_Per-Process Graphics Translation Table_) s’améliore, mais quelques régressions de dernière minute ont empêché l’ajout des dernières parties nécessaires pour sa gestion complète. Espérons que la prochaine version apportera une gestion fonctionnelle et permettra d’isoler chaque processus dans un espace d’adressage différent ! La partie noyau de gestion de l’extension OpenGL [`GL_ARB_robustness`](https://www.opengl.org/registry/specs/ARB/robustness.txt) vient également d’être intégrée. Le rôle de cette extension OpenGL est de permettre aux applications de réagir à la perte de leur contexte graphique, dans le cas où le matériel aurait planté ou été mis en pause (Optimus). Le reste des modifications concerne la gestion de l’affichage et sa gestion d’énergie. Pour plus d’informations, vous pouvez consulter [l’article de _blog_ de Daniel Vetter](http://blog.ffwll.ch/2014/01/neat-drmi915-stuff-for-314.html), mainteneur du _i915_. ### NVIDIA (pilote nouveau) La gestion initiale de l’accélération pour les processeurs graphiques _GK110_ et _GK208_ (_NVF0_ et _NV108_) fait son apparition dans le noyau 3.14 grâce à Ben Skeggs. Cette gestion est incomplète car elle requiert aussi des modifications dans le pilote _nvc0_ de Mesa 3D, à cause du changement d’[architecture de processeur](http://fr.wikipedia.org/wiki/Architecture_de_processeur) (ISA). Elle est cependant suffisante pour faire tourner GNOME Shell. Ilia Mirkin a corrigé une bonne partie des problèmes de génération d’instructions dans Mesa 3D. Ces modifications devraient être disponibles dans la version 10.2. La gestion de l’affichage des erreurs a également été améliorée par Ilia et Ben, afin de mieux pouvoir diagnostiquer les problèmes remontés par la carte. En parlant d’affichage, la gestion des superpositions vidéo (_video overlays_) pour les puces graphiques _NV10_ à _NV40_ vient d’être dévoilée par Ilia, grâce à l’interface de plans d’affichage KMS (KMS planes). Il faudra des modifications dans _xf86-video-nouveau_ pour que les applications en espace utilisateur puissent l’exploiter. Le travail de fond pour la gestion d’énergie continue, mais rien n’a encore été soumis. Voir la [demande d’intégration](http://cgit.freedesktop.org/~airlied/linux/commit/?id=76f4f415e502e4dfaf409edd0d4ed0dd3a0a0419). ### OMAP (pilote omap) Peu de nouveautés du côté du pilote OMAP, qui ajoute la gestion du _Device Tree_ pour le bloc [TI DMM](http://www.linuxplumbersconf.org/2010/ocw/proposals/549) (_Dynamic Memory Manager_). Le reste des modifications corrige des bogues au démontage à chaud du pilote _omap_. Voir la [demande d’intégration](http://www.spinics.net/lists/dri-devel/msg51420.html). ### Renesas R-Car DU (pilote rcar-du) La principale nouveauté du pilote Renesas _rcar-du_ est l’ajout de la prise en charge du _R8A7791 DU_ qui est une version allégée du _R8A7790 DU_ avec uniquement deux contrôleurs vidéo ([CRTC](https://en.wikipedia.org/wiki/Video_Display_Controller)), gérant donc deux écrans maximum, et une unique sortie [LVDS](https://en.wikipedia.org/wiki/LVDS) (liaison habituelle pour les écrans d’ordinateurs portables). Le reste des modifications se limite à l’aspect cosmétique du code et à la correction de bogues matériels, avec l’ajout de rustines pour la sélection des voies LVDS. Voir la [demande d’intégration](http://www.spinics.net/lists/dri-devel/msg49697.html). ### Tegra (pilotes host1x et tegra) Cette nouvelle version du pilote _host1x_ apporte une gestion initiale des systèmes monopuces basés sur le _Tegra124_. Le pilote DRM _tegra_ se voit aussi recevoir une gestion partielle de _Prime_, ce qui va permettre au Tegra (le processeur graphique) d’afficher les images calculées à l’écran grâce à _host1x_ sans faire de copies. Il est également maintenant possible de désactiver la gestion de _fbdev_ à la compilation, même s’il sera compilé par défaut. Les motivations pour ce travail doivent être les mêmes que pour Intel. Le reste des changements apportés est lié à _host1x_ et au contrôleur d’affichage. Plus d’écrans sont gérés, et l’utilisation de l’interface HDMI est plus économe en énergie. Voir la [demande d’intégration](http://cgit.freedesktop.org/~airlied/linux/commit/?id=785e15ecefbfe8ea311ae320fdacd482a84b3cc3). ### VMware (pilote vmwgfx) Pas de changement visible pour le pilote _vmwgfx_ dans cette version. Le travail a uniquement consisté en l’écriture de la gestion pour l’allocation de ressources graphiques en utilisant la mémoire de la machine virtuelle. Ces ressources sont les contextes graphiques, les textures et les [_shaders_](http://fr.wikipedia.org/wiki/Shader). Cette gestion permettra l’implémentation des pilotes pour la version 11 de la carte graphique virtuelle _SVGA2_. Maintenant que les modifications sont disponibles dans le noyau, des correctifs pour Mesa 3D devraient bientôt arriver pour gérer l’allocation locale de mémoire. Voir la [demande d’intégration](http://www.spinics.net/lists/dri-devel/msg51911.html). ## Réseau ### Adresses IPv6 temporaires en espace utilisateur En IPv6, l’auto‐configuration des adresses est la règle par défaut. Cela a conduit à une gestion des adresses en espace noyau : à la réception d’une annonce de routeur, le noyau se charge d’attribuer une adresse globale statique dérivée de l’adresse MAC, et une adresse aléatoire temporaire, si la variable _sysctl_ `use_tempaddr` est au moins à 1. C’est bien beau et pratique, mais des outils en espace utilisateur ont parfois envie de prendre la main. L’exemple le plus typique et le plus connu est probablement NetworkManager. Ces outils pouvaient déjà, bien entendu, ajouter ou supprimer des adresses, mais uniquement des adresses permanentes. Impossible d’ajouter une adresse considérée comme temporaire par le noyau. Il serait évidemment possible de mettre un minuteur pour supprimer l’adresse depuis l’espace utilisateur, mais cela n’aurait pas les mêmes effets (une adresse temporaire est marquée comme obsolète par le noyau et n’est pas supprimée directement après son expiration). Un nouveau drapeau de configuration des adresses a donc été ajouté, permettant l’ajout d’une adresse temporaire depuis l’espace utilisateur. Cela permettra aux outils en espace utilisateur de prendre totalement la main sur la configuration IPv6, et permettra aussi d’ajouter plus tard les adresses temporaires obtenues par DHCPv6. Pour l’anecdote, cette fonctionnalité a eu des conséquences sur `ifconfig` durant le cycle de développement. En effet, `ifconfig` lit le fichier `/proc/net/if_inet6` pour déterminer les adresses assignées à une interface. L’ajout de l’information du drapeau « adresse temporaire » cassait cette lecture, et a donc été retirée (l’information reste lisible par l’interface _netlink_). C’est un bon rappel pour ceux utilisant encore les vieux outils : `ifconfig` et les outils associés sont obsolètes et ne renvoient que des informations incomplètes sur l’état réel de la configuration réseau. La bonne méthode est d’utiliser les outils apportés par `iproute` (_cf._ [cet article](http://techblog.rosedu.org/ifconfig-vs-iproute.html)). ###Bouchon automatique sur TCP Les développeurs noyau de Google sont très intéressés par les performances réseau du noyau Linux, en particulier du protocole TCP (par exemple avec [RPS et RFS](http://linuxfr.org/news/nouvelle-version-2635-du-noyau-linux#long4)). Pour cette version, ils ont développé des « bouchons » automatiques sur une [_socket_](http://fr.wikipedia.org/wiki/Berkeley_sockets) TCP. Mais qu’est‐ce qu’un bouchon ? Le principe est ancien : une application peut depuis très longtemps mettre l’option `TCP_CORK` sur une _socket_, ce qui bloque l’envoi de petits paquets. Les écritures de l’application sur le _socket_ sont alors placées dans une file d’attente, qui peut ensuite se vider dans deux situations : - partiellement, si elle est suffisante pour envoyer une trame complète ; - complètement, quand l’application enlève le bouchon en désactivant l’option. L’intérêt est de gagner en performance : chaque paquet TCP étant coûteux, il est plus simple et potentiellement plus rapide d’envoyer un gros paquet qu’une dizaine de petits. C’est bien beau, mais cette option demande une coopération fine de l’application. Tout repose sur elle, qui doit mettre le bouchon et l’enlever au bon moment. Éric Dumazet, développeur chez Google, propose donc d’optimiser tout ça automatiquement. À présent, quand le noyau reçoit de nouvelles données à mettre dans une _socket_ TCP, il vérifie deux choses. La première est la taille du paquet. S’il est suffisamment grand, il est ajouté dans la queue à transmettre. En revanche, si le paquet est trop petit, il se peut qu’il soit pertinent d’attendre un peu avant de le placer dans la queue. Le noyau regarde donc s’il y a des paquets déjà en attente d’envoi. Si c’est le cas, on peut attendre, la carte réseau a déjà du travail, cela ne retarde rien de ne pas mettre le paquet dans la pile immédiatement. Le paquet sera mis à la fin du vidage de la file. Ce petit délai donne une chance de grouper plusieurs messages de l’application dans le même paquet. Ce qui ressemble à une petite optimisation permet des gains de performance inattendus dans certains cas, à la fois en termes de débit utile et de temps processeur utilisé. Pour désactiver cette fonctionnalité, une nouvelle variable _sysctl_ existe : `/proc/sys/net/ipv4/tcp_autocorking`. On peut aussi s’amuser à compter les paquets bouchonnés avec `netstat -a | grep TcpExtTCPAutoCorking`. Le bouchon manuel est, quant à lui, toujours disponible pour les applications capables d’anticiper leurs besoins. ###Petites nouvelles de nftables [_nftables_](http://netfilter.org/projects/nftables/), ou le nouveau pare‐feu sous Linux, a été intégré dans le précédent noyau 3.13. Cette version contient donc logiquement de nombreuses corrections, suite aux retours des nouveaux utilisateurs. Dans les fonctionnalités, on notera l’apparition d’une nouvelle table `inet`, permettant d’ajouter des règles pour IPv4 et IPv6 simultanément. Pratique pour la cohérence des règles sur les deux protocoles, notamment celles qui concernent des ports à ouvrir pour TCP et UDP. De quoi simplifier la vie des administrateurs, obligés de jongler entre `iptables` et `ip6tables`, ou d’utiliser un outil de haut niveau pour générer les règles. ###Du débogage pour BPF Le [_Berkeley Packet Filter_](http://fr.wikipedia.org/wiki/BSD_Packet_Filter) est régulièrement cité dans les dépêches noyau, par exemple, pour la [version 3.0](http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_14). Pour rappel, il permet aux applications analysant le réseau de ne pas capturer l’ensemble des paquets, mais seulement une partie, que le noyau se charge de trier en fonction de règles définies par l’application. Les développeurs de ces applications seront heureux de découvrir un débogueur permettant de simplement vérifier l’exécution du filtre avant de réellement l’exécuter. Pour utiliser ce débogueur, il existe un programme `bpf_dbg` prêt à l’utilisation, dans le dossier `tools/net` des sources du noyau. Toujours dans ce dossier, le nouvel outil `bpf_asm` permet de compiler de l’assembleur BPF en espace utilisateur pour l’insérer ensuite directement dans le noyau. Cela est normalement réservé à des usages très particuliers pour des développeurs ne pouvant pas utiliser la bibliothèque `libpcap`. Soit parce qu’elle manque de fonctionnalités, soit parce qu’elle ne peut être intégrée sur le système, soit parce que le développeur veut utiliser le compilateur JIT ([décrit dans la dépêche noyau 3.0](http://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_14)), etc. [Une fois n’est pas coutume](http://marc.info/?l=linux-netdev&m=139053383018452&w=2), la série de correctifs contient aussi une [mise à jour de la documentation](https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next/+/7924cd5e0b3acaeafd0d7628d9e9fb8488b8fb13^!/#F0) de BPF. ## Systèmes de fichiers ### ext4 Rien de bien croustillant pour le système de fichiers ext4 cette fois‐ci. Correction d’une régression dans _bigalloc_, activation par défaut de la fonction _punch hole_ — toujours pour _bigalloc_ — et aussi quelques autres mises à jour diverses et éparses pour un total de neuf _commits_. Pour plus de détails sur les changements d’ext4, voir [_ici_](https://lkml.org/lkml/2014/1/28/253). ### Btrfs Bien que les changements apportés à ext4 et XFS ne soient pas extraordinaires, le système de fichiers Btrfs avance à grands pas. Chris Mason a écrit dans sa [demande d’intégration](http://lkml.iu.edu//hypermail/linux/kernel/1401.3/03045.html) : « C’est un gros morceau : la plupart de ces changements sont dans _btrfs-next_ depuis très longtemps. » Changements majeurs : - ajout des propriétés des nœuds d’index (_inodes_) (Filipe David Borba Manana) ; - exportation des infos du système de fichiers dans _sysfs_ (Jeff Mahoney) ; - énormément d’améliorations de performance. _[Adapté d’un [article de Phoronix](http://www.phoronix.com/scan.php?page=news_item&px=MTU4ODA)]_ ### F2FS F2FS, Flash‐Friendly File System, un système de fichiers écrit spécifiquement pour les mémoires Flash NAND, continue son évolution. Celui‐ci est écrit et maintenu par Kim Jaegeuk, employé par Samsung, et vise à fournir une meilleure prise en charge des matériels tels que les cartes SD ou autres disques durs SSD. Dans cette dernière fournée, F2FS se voit ajouter de nouvelles options afin de modifier son comportement durant l’exécution : _small_discards_, _max_victim_search_ et _in-place-update_. Les performances en lecture‐écriture sont améliorées dans certaines situations et la gestion des données _inline_data_ (amélioration du stockage des petits fichiers) est commencée. Comme souvent, ce fut aussi l’occasion de réaliser du nettoyage de code et de clore plusieurs rapports d’erreurs. Voir la [demande d’intégration](http://lkml.iu.edu//hypermail/linux/kernel/1401.2/03491.html). ### kernfs _kernfs_ est une version plus générique de [_sysfs_](http://fr.wikipedia.org/wiki/Sysfs), afin que d’autres sous‐systèmes puissent l’utiliser pour créer leur propre système de fichiers virtuel. Ces sous‐systèmes bénéficieront ainsi facilement des attributs propres à _sysfs_ (gestion de la déconnexion d’un périphérique, création et suppression d’entrées dynamiques...). _sysfs_ a donc été modifié pour utiliser _kernfs_ ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d3bad75a6d57416cf7478ca2a1e42f699bc17ec5)), et le système de fichiers virtuel utilisé pour représenter les [_cgroups_](http://fr.wikipedia.org/wiki/Cgroups) en espace utilisateur est en cours de conversion ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f075e0f6993f41c72dbb1d3e7a2d7740f14e89e2)). La conversion de [_debugfs_](http://en.wikipedia.org/wiki/Debugfs) est aussi prévue. Attention à ne pas confondre avec le [_kernfs_ de NetBSD](http://en.wikipedia.org/wiki/Kernfs). Pour rappel, _sysfs_ est un système de fichiers virtuel introduit dans le noyau 2.5. Il permet de fournir à l’espace utilisateur des informations sur le matériel et ses pilotes. Plus concrètement parlant, _sysfs_ permet de fournir une méthode générique de chargement à chaud (_hot plug_), un arbre de relation générique entre un matériel son unité logique (_device tree_), mais aussi de simplifier _procfs_. Cette mise à jour fut fournie par Patrick Mochel, puis corrigée par Maneesh Soni. ### RBD En parlant stockage, et bien qu’il ne s’agisse pas d’un système de fichiers, un problème de stabilité a été résolu dans le module RBD (le « périphérique de type bloc » des grappes de serveurs [Ceph](http://fr.wikipedia.org/wiki/Ceph_%28stockage%29)), qui pouvait provoquer une panique du noyau (_kernel panic_) à haut régime. ## Sécurité ### Audit Le système d’audit change temporairement de code de retour d’erreur dans certains cas. Cela concerne principalement les utilisateurs de conteneurs qui devaient jusqu’à présent désactiver l’audit pour pouvoir ouvrir une session dans un conteneur ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa4af831bb4f3168f2f574b2620124699c09c4a3)). Ce _commit_ est un bidouille temporaire, un correctif propre sera proposé pour inclusion dans le 3.15 ([_bugzilla_](https://bugzilla.redhat.com/show_bug.cgi?id=893751)) à la suite des [changements déjà implémentés dans le 3.13](https://linuxfr.org/news/sortie-de-linux-3-13#audit). Cet bidouille est similaire à [celle déjà implémentée dans _systemd-nspawn_](https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/cF6zVDjKDuu). D’autres bogues liés à l’interaction d’audit avec les espaces de noms ont été corrigés ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=adf961d7e8006d2cb16ceee07582b145b9ef69f7)). Chaque changement dans la configuration des éléments audités tracera les informations du processus l’ayant effectué ([commit](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ad2ac263278620205555a572c29b3ebb4a5bce3b)). La taille du tampon de stockage temporaire des messages d’audit peut être illimitée (seulement limitée par la quantité de mémoire vive ([_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=40c0775e5ea47667db497565b79a8dc154530992)). Le journal généré lors d’un plantage et de la création d’un _core dump_ contient le nom de l’exécutable qui a planté ([_commit_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff235f51a138fc61e1a22dcb8b072d9c78c2a8cc)). Le code a été globalement retravaillé ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6dd9158ae8577372aa433e6b0eae3c3d4caa5439)). ### Protection de la pile à la compilation par GCC (GCC stack protector) La version 4.9 de du compilateur GCC gèrera l’option `-fstack-protector-strong`, qui se positionne entre `-fstack-protector` et `-fstack-protector-all`. Ces options activent la [protection de la pile à l’aide de canaris](http://en.wikipedia.org/wiki/Buffer_overflow_protection), qui consiste à détecter et ainsi prévenir les effets néfastes des dépassements de tampon. Cette nouvelle option choisit plus judicieusement dans quels cas la protection est appliquée à une fonction. Cela évite d’avoir à choisir entre protéger toutes les fonctions (même celles pour lesquelles la protection n’est pas vraiment nécessaire) et ne protéger que très peu de fonctions (seulement 2,81 % avec `-fstack-protector`). Kees Cook a ajouté la [gestion de cette option dans le noyau Linux](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ad3ab302fd8239a1ddee01e606683c3197ca6908). Les détails sont sur son [_blog_](http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/) avec le [document de travail pour l’implémentation dans GCC](https://docs.google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/edit?pli=1). ### Intel Memory Protection Extensions (MPX) Le noyau Linux 3.14 inclut les [bases de l’infrastructure pour gérer l’extension matérielle MPX](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c9cdd9a6ae49704f12a289706551536ec842693f), pour l’instant spécifique aux futurs processeurs Intel. Les fonctionnalités, elles‐mêmes, seront incluses plus tard. L’[extension MPX](http://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions) vise à mieux protéger le système des vulnérabilités de type dépassement de tampon. Pour cela, des registres supplémentaires seront introduits pour stocker les valeurs maximales et minimales que peuvent prendre certains pointeurs. Lorsque l’un de ces pointeurs est déréférencé, l’adresse est comparée aux valeurs précédemment stockées dans les registres. Les accès en dehors de ces limites déclenchent une exception #BR (_boundary range exceeded_) qui peut ainsi être traitée soit par le noyau, soit par le programme en espace utilisateur. À terme, la prise en charge devrait fonctionner pour les programmes en espace utilisateur ainsi que pour le noyau (la gestion pour l’hyperviseur KVM est prévue). Ces protections sont contrôlées séparément. La prise en charge complète de MPX nécessite donc des [changements dans les compilateurs](http://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-extensions-intel-mpx-support-in-the-gnu-toolchain). En outre, la protection n’est pas « tout ou rien », car un programme peut fonctionner même si seulement une partie du code est compilée pour MPX, et ce même code sera aussi [fonctionnel sur les processeurs ne gérant pas l’extension](http://software.intel.com/en-us/blogs/2013/07/23/intel-memory-protection-extensions-intel-mpx-design-considerations). ### kALSR _kASLR_ (_kernel Address Space Layout Randomization_ ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f4bcd8ccddb02833340652e9f46f5127828eb79d)) consiste à rendre aléatoire l’adresse physique et l’adresse virtuelle à partir de laquelle est décompressé le noyau Linux lors de la phase de démarrage. Ceci devrait rendre un peu plus difficile l’exploitation de vulnérabilités dans le noyau, puisqu’un attaquant ne pourra plus simplement utiliser une même adresse statique sur tous les systèmes vulnérables (et avec la même version du noyau). Il lui faudra au préalable récupérer une adresse mémoire d’un élément dans le noyau (_memory infoleak_) pour pouvoir calculer l’adresse de la structure ou fonction à utiliser dans une exploitation de vulnérabilité. Comme cette étape se déroule très tôt au démarrage du système, les contraintes de placement en mémoire sont fortes et l’entropie disponible est faible. Il n’est donc possible d’utiliser que 9 bits d’entropie pour l’architecture AMD64 et 8 bits pour l’architecture x86. Les développeurs du correctif [_grsecurity_](http://grsecurity.net/) ont vivement critiqué cet ajout, car il n’apporte que très peu d’avantages en termes de sécurité. En effet, les vulnérabilités de type fuite d’information sont assez courantes dans le noyau Linux, et elles ne sont pas corrigées avec la même rapidité que les failles plus immédiatement critiques. Une explication détaillée est disponible sur le [_blog_ de _grsecurity_](http://forums.grsecurity.net/viewtopic.php?f=7&t=3367). **Note importante :** l’hibernation n’est pour l’instant plus possible avec un noyau configuré avec _kASLR_ ([option `RANDOMIZE_BASE`](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/Kconfig#n1701)). ### Vérification des copies entre espaces utilisateur et noyau Une première étape vers plus de vérification sur les copies entre espace utilisateur et espace noyau a été ajoutée sous forme de module noyau vérifiant les appels à _copy_to/from_user_ ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3e2a4c183ace8708c69f589505fb82bb63010ade)). Les erreurs à ce niveau sont justement souvent source de bogues ou de fuites d’information. ### Trousseaux de clés Plusieurs bogues dans la gestion des trousseaux de clés par le noyau ont été corrigés ([1](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5dec682c7f33a765a5eb764cc18b1d02b17cd762), [2](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a81bddde96147442e1e365de5d215f7f154b5027)). ### LSM #### SELinux La politique SELinux stockée dans le noyau incorporera les informations nécessaires aux outils en espace utilisateur pour déterminer quelle contrainte a levé une interdiction ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a660bec1d84ad19a39e380af129e207b3b8f609e)). Les [contraintes SELinux](https://wiki.gentoo.org/wiki/SELinux/Constraints) sont un ensemble de règles d’une politique qui ont précédence sur toutes les autres règles. Elles sont vérifiées à l’exécution, d’où l’importance de ce correctif dans l’investigation des erreurs de ce type. Les contraintes sont particulièrement utilisées dans la politique de [sécurité multi‐niveau](http://fr.wikipedia.org/wiki/S%C3%A9curit%C3%A9_multiniveau) (MLS). Les étiquettes de sécurité (_security labels_) associées à des paquets IPsec seront vérifiées à la fois pour les paquets entrants (ce qui est fait actuellement) et les paquets sortants ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b67c493248059909d7e0ff646d8475306669b27)). Il est en effet possible de [marquer les paquets IPsec](http://selinuxproject.org/page/NB_Networking) avec des étiquettes SELinux pour qu’elles soient interprétées par le destinataire. Le composant _netfilter_ peut alors prendre des décisions de filtrage en fonction de ces étiquettes. #### SMACK Les exécutables ne peuvent plus être étiquetés avec « * » ou « @ », car les fichiers qu’ils créeraient ne disposeraient pas de restrictions suffisantes par (« * » signifie que tout le monde peut lire le fichier), ce qui est contraire aux principes du contrôle d’accès obligatoire _— Mandatory Access Control_, MAC — ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19760ad03cc639d6f6f8e9beff0f8e6df654b677)). Le contrôle du _socket_ `/dev/log` était limité par défaut aux processus avec l’étiquette « _ ». Or, le système Tizen n’utilise cette étiquette que pour un nombre très limité de processus. Il fallait donc autoriser l’administrateur à définir une étiquette personnalisée chargée de la gestion de ce _socket_. La nouvelle valeur par défaut est « * », ce qui autorise l’accès par n’importe quelle étiquette. Pour restreindre à nouveau l’accès, il suffit d’écrire l’étiquette désirée dans `smakfs/syslog` ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=00f84f3f2e9d088f06722f4351d67f5f577abe22)). Les contrôles SMACK effectués lors du montage de systèmes de fichiers sans droits particuliers (utilisateurs autres que le super‐utilisateur _root_) étaient trop laxistes et pouvaient permettre à un processus d’effectuer des opérations nécessitant la capacité `CAP_MAC_ADMIN` en temps normal. Il n’est ainsi plus possible d’indiquer des options SMACK lors d’un montage non privilégié. Cette fonctionnalité sera potentiellement réactivée plus tard, si un modèle valide est trouvé pour gérer ce cas ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=24ea1b6efcd8fc3b465fb74964e1a0cbe9979730)). Un autre petit changement corrigeant une vulnérabilité potentielle a été ajouté ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4afde48be8929b6da63a9e977aaff0894ba82984)). ### Chiffrement Ajout de versions de l’algorithme AESNI-GCM exploitant les jeux d’instructions AVX et AVX2 ([_commit_](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d764593af924930d5c15685bc5946cb943da1a55)) optimisant les opérations de chiffrement et de déchiffrement pour des blocs de données de grandes tailles. Les gains sont de 6, 11 et 18 % pour des blocs respectivement d’une taille de 1, 2 et 8 Kio, par rapport aux versions des ces algorithmes exploitant les instructions SSE. Les gains devraient être encore plus importants pour les futurs processeurs Intel. ## Virtualisation ### KVM Du côté d’Intel, la virtualisation imbriquée (qui consiste à avoir les machines virtuelles qui exposent les instructions de virtualisation, ce qui permet d’avoir un hyperviseur en machine virtuelle sans problème de performance, très pratique pour tester une solution de virtualisation sur son portable) est corrigée, car elle n’était plus disponible depuis le noyau 3.13. Pour les architectures ARM, la supervision du contrôleur d’interruptions est désormais possible, ce qui permet la migration à chaud de machines virtuelles. Pour les ordinateurs centraux (_mainframes_) IBM (s390), il y a la prise en charge des transactions et de la « aptitude au paramètre de charge du programme pour les invités » ([_Load Program Parameter_](http://www-01.ibm.com/support/docview.wss?uid=isg26fcd1cc32246f4c8852574ce0044734a&aid=1) _facility for guests_), cette dernière est un prérequis pour avoir un compteur de performance matériel sur ces processeurs. Enfin, toujours chez IBM, l’architecture [POWER](http://fr.wikipedia.org/wiki/IBM_POWER) accepte les invités « [petit‐boutiste](http://fr.wikipedia.org/wiki/Petit-boutiste) » et prend en charge des nouveautés des POWER 8. Il y a eu deux demandes d’intégration concernant KVM auxquels vous pouvez vous référer pour plus d’informations : [_1_](http://lkml.iu.edu//hypermail/linux/kernel/1401.2/03129.html) et [_2_](http://lkml.iu.edu//hypermail/linux/kernel/1401.3/02422.html). ### Xen Cette version apporte deux nouveautés majeures dans Xen. Premièrement, l’extensibilité du canal des événements matériels (IRQ). Au lieu d’avoir une table à deux niveaux par processeur, il y a maintenant une file [FIFO](http://fr.wikipedia.org/wiki/First_in,_first_out) avec priorité, ce qui permet d’avoir une plus faible latence, de gérer plus d’événements et d’être plus extensible. La deuxième fonctionnalité est le mode PVH ; pour ceux qui ne connaissent pas Xen, il y a plusieurs modes. Le premier est le mode paravirtualisé (PV), qui implique l’utilisation d’un noyau invité prévu pour fonctionner avec Xen, mais qui offre des fonctionnalités intéressantes comme des bonnes performances avec un processeur 32 bits ne prenant pas en charge les instructions de virtualisation ; et le fait de ne pas devoir émuler le matériel. L’autre mode est le mode _Hardware Virtual Machine_ (HVM) qui virtualise classiquement le système et permet de faire tourner n’importe quel système d’exploitation. Le mode paravirtualisé pose problème avec les invités 64 bits, car les appels système sont lents. Cela est dû au fait que sur 32 bits, Xen utilise la segmentation de la mémoire du processeur, mais comme cette fonctionnalité était utilisée par très peu d’applications, AMD l’a supprimée des instructions 64 bits, et Xen doit faire plus de travail de vérification pour éviter les failles. Pour résoudre ce problème, l’équipe a décidé d’utiliser l’infrastructure de virtualisation des processeurs pour la paravirualisation : ce mode hybride est le PVH. Il permet d’avoir des invités beaucoup plus réactifs en 64 bits, et beaucoup moins de code dans le noyau. Pour plus d’information sur le PVH, vous pouvez regarder la vidéo (en anglais) de la conférence du [FOSDEM](http://fr.wikipedia.org/wiki/FOSDEM "Free and open source software developers’ European meeting") : _[How we ported FreeBSD to PVH](http://video.fosdem.org/2014/UD2120_Chavanne/Sunday/How_we_ported_FreeBSD_to_PVH.webm)_, et lire la [demande d’intégration](http://lkml.iu.edu//hypermail/linux/kernel/1401.2/03298.html). #Divers Pour ceux à qui cette dépêche aurait donné l’envie d’ouvrir le capot et mettre les mains dans le moteur, il n’est pas trop tard pour vous inscrire au [_Challenge Eudyptula_](http://eudyptula-challenge.org). Le but est, petit à petit, d’amener les participants via des exercices progressifs à apprendre à utiliser les outils nécessaires et comprendre les règles du développement du noyau Linux. L’[_Eudyptula Minor_](http://fr.wikipedia.org/wiki/Manchot_pygm%C3%A9e) est le nom scientifique du manchot Pygmée bien connu des [Linuxiens](http://fr.wikipedia.org/wiki/Tux#Historique). # Le bilan en chiffres En ce qui concerne les statistiques du cycle de développement du noyau 3.14, le site _LWN.net_ a publié son traditionnel [article récapitulatif](https://lwn.net/Articles/590354/) et l’on peut également se reporter 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 300, soit légèrement au‐dessus des 12 122 correctifs du noyau 3.13. Ces ajouts sont le résultat du travail d’environ 1 500 développeurs soit, là encore, une hausse notable par rapport aux 1 402 développeurs du noyau précédent. C’est Intel qui occupe la tête du classement des entreprises, avec une marge assez confortable par rapport à Red Hat. Rappelons toutefois que la hiérarchie s’inverse complètement quand on examine les _tags_ de type « _signoffs_ ». Ces _tags_ sont employés par les mainteneurs pour marquer leur approbation d’un changement. Dans ce rôle de gardien des portes du noyau, les développeurs employés par Red Hat représentent (selon LWN) 20 % des _tags_ de type « _signoffs_ », alors que les développeurs d’Intel ne sont qu’à 11,8 % et ceux de la Fondation Linux sont à 13,4 % (il s’agit essentiellement de [Greg Kroah‐Hartman](http://fr.wikipedia.org/wiki/Greg_Kroah-Hartman)). # 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), [Thomas Debesse](https://linuxfr.org/users/illwieckz) **Arch** | [Romain Perier](https://linuxfr.org/users/rperier) | **Pilotes graphiques libres** | [Martin Peres](https://linuxfr.org/users/mupuf) | **Réseau** | [Florent Fourcot](https://linuxfr.org/users/ffourcot) | **Systèmes de fichiers** | [_Jiehong_](https://linuxfr.org/users/jiehong) (inactif) | [Timothée Ravier](https://linuxfr.org/users/siosm) **Sécurité** | [Timothée Ravier](https://linuxfr.org/users/siosm) | **Virtualisation** | [Xavier Claude](https://linuxfr.org/users/claudex) | **Édition générale** | | [Martin Peres](https://linuxfr.org/users/mupuf), [_Mali_](http://linuxfr.org/users/mali), [Patrick_g](https://linuxfr.org/users/patrick_g) 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. Il n’y a 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. Essayons d’augmenter la couverture sur les modifications du noyau !

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