URL: https://linuxfr.org/news/sortie-du-noyau-linux-4-9 Title: Sortie du noyau Linux 4.9 Authors: Collectif gusterhack, FantastIX, Oliver, Davy Defaud, esdeem, palm123, BAud, Yves Bourguignon, ɹǝıʌıʃO, jcr83, ZeroHeure, Benoît Sibaud, superna, ariasuni, M5oul, barmic, ʭ ☯ , Ph Husson, reynum, Rafael, Nicolas Boulay, Surfoo, plic, scorpio810, skone et Philip Marlowe Date: 2016年10月17日T09:12:22+02:00 License: CC By-SA Tags: sortie_version, noyau_linux, f2fs, plagiat, linus_torvalds, grsecurity et lwn Score: 92 La sortie de la version stable 4.9 du noyau Linux a été annoncée le dimanche 11 décembre 2016 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 (qui est sous licence CC BY-SA). [![Les deux filles nerds implémentent BBR, un nouvel algorithme d’évitement de congestion TCP pour remplacer les douze autres algorithmes. Mais, à la fin, l’algorithme BBR, intégré dans Linux 4.9, n’est pas le meilleur dans tous les cas. Et les filles se rendent compte que maintenant elles font face à treize algorithmes et aucun pour remplacer les autres dans tous les cas !](https://cpp-frug.github.io/materials/images/nerd_nouvel_algo_bbr.svg)](https://github.com/cpp-frug/materials/blob/gh-pages/images/nerd_nouvel_algo_bbr.svg) ---- [Dépêches des noyaux précédents](https://linuxfr.org/wiki/depeches_noyau) [Site officiel du noyau Linux](https://www.kernel.org/) [Les nouveautés du noyau 4.9](http://news.softpedia.com/news/linux-kernel-4-9-officially-released-with-support-for-amd-radeon-si-gcn-1-0-gpus-510879.shtml) ---- Annonces des versions candidates par Linus Torvalds =================================================== RC-1 --- La version [RC-1](https://lkml.org/lkml/2016/10/15/112) est sortie le samedi 15 octobre 2016 : Habituellement, je fais mes publications le dimanche après‐midi, mais de temps en temps, je raccourcis la fenêtre d’intégration d’un jour, pour garder les gens en alerte et m’assurer qu’ils ne se mettent pas à envoyer leurs demandes d’intégration [N. D. T. : _pull requests_] à la dernière minute. Ce n’est pas le dernier jour qu’on s’amuse à jouer avec la fenêtre d’intégration. Idem pour celle‐ci. Pour être honnête, la raison qui m’a poussé à la sortir un jour plus tôt pour cette fois‐ci est moins d’empêcher les gens de jouer contre la montre avec leurs contributions, mais bien plus parce que cette fenêtre d’intégration était plutôt imposante et pas particulièrement réjouissante. J’ai dû arrêter la fusion par deux fois pendant cette fenêtre d’intégration, uniquement parce que je traquais divers problèmes. C’est ce qui a tendance à faire passer ma période d’activité sur la fenêtre de fusion du mode « occupé » à « légèrement stressant ». Mais, bon, tout va bien maintenant. Et, même si la 4.9 semble être une grosse version et que nous avons eu quelques couacs, dans l’ensemble, les choses semblent normales. La grande nouveauté est l’ajout de Greybus, dont Greg jure qu’il est vraiment utilisé. Mais, sous le capot, le plus gros des modifications est, en réalité, tout un tas de petits détails, comme d’habitude. Dans les « petits détails de dessous le capot », il se trouve que mon préféré concerne les nouvelles [allocations de piles virtuelles du noyau](_#allouer-les-piles-dexécution-du-noyau-en-mémoire-virtuelle_) par Andy Lutomirski. Elles simplifient la découverte et la récupération des débordements de la pile. L’effort a également permis de nettoyer du code et d’ajouter un cache de correspondance à la pile du noyau pour éviter des baisses de performance. Al a aussi travaillé sur quelques nettoyages de VFS et _uaccess_ que j’ai suivis (en particulier un truc puant dans un modèle de liaison). Mais soyons réalistes : ce que **je** considère comme des petits détails sympas sont juste mes propres marottes, il y en a un peu partout. Il se fait que le système de pile virtuelle signifie aussi qu’il est grand temps pour ceux qui ont la sale manie de faire des accès directs en mémoire ([DMA](https://fr.wikipedia.org/wiki/Acc%C3%A8s_direct_%C3%A0_la_m%C3%A9moire)) à l’aide de variables temporaires allouées sur la pile (« Ne faites pas ça ! ») de changer leurs habitudes. Cela aura des retombées et je m’attends à ce qu’il y ait quelques pilotes à corriger çà et là. Mais tout ceci est pour une bonne cause, vraiment (et ce n’est pas un usage très répandu, parce que faire un accès direct à la mémoire depuis la pile n’a jamais été une bonne idée et, de manière générale, même pas envisageable dans la plupart des situations). Mais il y a vraiment beaucoup d’autres choses en cours et le sommaire des modifications, tel que je le fais pour les autres versions, est bien trop long pour la RC-1. Donc, comme d’habitude, j’adjoins mon « journal de fusion » à la place, ce qui donne une vue de très haut niveau de ce que j’ai fusionné et de qui cela provient. Et, comme d’habitude, je tiens à souligner que les personnes dont proviennent les contributions que je fusionne ne sont pas nécessairement celles qui ont fait le travail : nous avons eu 1 500 personnes impliquées dans cette version, seuls les mainteneurs de haut niveau sont cités dans mon journal de fusion. Allez‐y et testez, Linus RC-2 --- La version [RC-2](https://lkml.org/lkml/2016/10/23/203) est sortie le dimanche 23 octobre 2016 : Je suis de retour sur mon agenda de publication habituel le dimanche après‐midi et Linux 4.9-rc2 est disponible. Ma nouvelle fonctionnalité préférée, telle que je l’avais nommée dans l’annonce de la RC-1 (les piles virtuelles) est peut‐être impliquée dans des plantages que Dave Jones a essayé de comprendre. Donc, si vous voulez vous rendre utile et voir si vous pouvez fournir plus de données, s’il vous plaît, assurez‐vous d’avoir activé la variable `CONFIG_VMAP_STACK`. ... d’un autre côté, si tout ce que vous voulez est d’éviter les tracas engendrés par _ce_ problème particulier, désactivez les piles virtuelles pour l’instant ; mais, s’il vous plaît, aidez‐nous à tester. Parce que la 4.9 est clairement en phase d’être une grosse version (je n’ai pas encore fait de véritables statistiques, mais je pense que c’est la plus importante version que nous ayons jamais eue en nombre de modifications enregistrées [N. D. T. : _commits_]) et je pense que Greg prévoit aussi d’en faire une version LTS. Il se peut que les deux soient liés, avec tous ceux qui insistent pour que leurs trucs soient prêts. Bref, plus il y en a qui testent, plus tôt ils commencent à tester dans la série des RC, plus tôt nous en aurons fini. Un indice ! Un indice ! OK, sujet clos. La RC-2 elle‐même n’est pas énorme, mais c’est un cas fréquent : soit les gens prennent une pause après la fenêtre de fusion, soit c’est juste qu’il leur faut un moment avant de découvrir les retombées du nouveau code source ; donc, comme d’habitude, la RC-2 est dans le lot des petites versions. En revanche, nous avons des modifications un peu partout : les pilotes dominent (les pilotes graphiques sortent du lot, mais il y a [aussi] [IPMI](https://www.admin-linux.fr/ipmi-intelligent-platform-management-interface/), [_clocksource_](https://www.kernel.org/doc/Documentation/timers/timekeeping.txt), MMC, _pinctrl_, HID, SCSI, NVMe... En veux‐tu, en voilà). Ajoutez à cela quelques mises à jour d’architectures (x86 et ARM64), un peu de nettoyage sur les systèmes de fichiers (ext4, NFS, Ceph, F2FS), les machines virtuelles, plus un gros correctif et vous en avez à peu près fait le tour. Le sommaire des modifications ci‐joint donne quelques détails et, pour encore plus de détails, vous pouvez toujours parcourir l’arborescence Git en question. Linus ## RC-3 La version [RC-3](https://lkml.org/lkml/2016/10/29/405) est sortie le samedi 29 octobre 2016 : Je publie la RC-3 un samedi, non pas pour attraper tous ceux qui s’amuseraient à m’envoyer des trucs à la dernière minute, mais simplement parce que, demain, je pars en voyage pour le [_Kernel Summit_](http://events.linuxfoundation.org/events/linux-kernel-summit). Il s’avère que le bogue que nous pensions dû aux nouvelles piles virtuelles pendant les tests de la RC-2 n’avait rien à voir avec ça ; il s’agit d’un problème d'accès concurrents à la file d’attente des requêtes de blocs. Donc, ceux qui avaient désactivé la nouvelle fonctionnalité n’y échappaient pas du tout, alors que les personnes touchées étaient probablement, tout comme DaveJ, ceux qui effectuent des tests de montée en charge. Mais tout ça est corrigé maintenant et nous devrions être parés. Il y a également un tas d’autres corrections un peu partout. Les statistiques des modifications ont l’air un peu bizarres, avec les corrections sur XFS qui prennent quasiment autant de place que celles portant sur les pilotes ; mais ce sont principalement des corrections du nouveau code de [_reflink_][1] incorporé durant cette version. De toute façon, vous ne devriez pas avoir été touché, à moins que vous n’utilisiez les derniers trucs à la mode. [1]: https://lwn.net/Articles/331808/ "Article datant de 2009 par Jonathan Corbet sur les facettes de ce genre de fonction système" À part ça ? Tous les divers correctifs habituels de pilotes, mises à jour d’architectures, etc. Le sommaire des modifications ci‐joint n’est vraiment pas petit (comme on pouvait s’y attendre, la RC-3 était plus grosse que la RC-2), mais il est assez facile à parcourir pour avoir ne fût‐ce qu’une idée de ce qui s’est passé. Donc, allez‐y, testez. Linus ## RC-4 La version [RC-4](http://lkml.iu.edu/hypermail/linux/kernel/1611.0/02731.html) est sortie le samedi 5 novembre 2016 : C’est de nouveau un samedi après‐midi plutôt qu’un dimanche. Cette fois, c’est parce que je sentais que cette RC était déjà suffisamment grosse. Une part de cette taille vient probablement du seul fait que la 4.9 est énorme, avec quelques changements en profondeur : nous avons un certain nombre d’améliorations apportées aux pilotes et systèmes de fichiers qui ont provoqué une avalanche de problèmes du genre « _la pile est actuellement virtuellement mise en correspondance et les adresses physiques ne fonctionnent pas_ ». Mais une plus grande part est tout simplement due aux premières corrections réseaux venant juste d’arriver après la RC-3, ce qui représente une large portion de celle‐ci (environ un tiers en vrac, légèrement plus en nombre de modifications enregistrées [N. D. T. : _commits_] — réparti à la fois sur les pilotes et l’architecture réseau). Je ne vais pas mentir : ce n’est pas une petite RC, et j’aurais été plus heureux si elle l’avait été. Mais ce n’est pas déraisonnablement grand pour cette (grosse) version, donc ce n’est pas comme si je devais m’en inquiéter. J’envisage toujours de sortir cette version au bout de sept [versions] candidates, pour autant que les choses commencent à se calmer. Nous verrons ce que ça donne à mesure que nous nous rapprocherons de la date de sortie. Quoi qu’il en soit, environ la moitié des changements sont imputés aux pilotes (le réseau en étant une partie non négligeable, mais aussi les pilotes média, graphiques et autre bric‐à‐brac). Environ un tiers sont des mises à jour d’architecture (SPARC et MIPS se démarquent, mais il y a aussi x86 et PA-RISC, plus quelques petites mises à jour sur ARM). Pour le reste, on a essentiellement l’architecture réseau et une poignée d’autres changements (systèmes de fichiers, tests). Et Arnd est toujours en train d’éliminer ses erreurs de variables non initialisées, de sorte que nous espérons pouvoir réactiver cet avertissement pour la 4.9 finale. On verra bien. Le sommaire des modifications ci‐joint n’est pas petit, mais vous pouvez, genre, le parcourir et avoir un aperçu de ce qui s’est passé la semaine dernière. Linus ## RC-5 La version [RC-5](http://lkml.iu.edu/hypermail/linux/kernel/1611.1/04166.html) est sortie le samedi 13 novembre 2016 : De retour à mon agenda du dimanche, tout a l’air plutôt normal. Calme au début, avec la plupart des corrections qui tombent en fin de semaine. J’ai l’habitude, maintenant. Aucun doute là-dessus, tout a franchement diminué et, malgré l’embonpoint de la 4.9, un agenda de sortie habituel semble encore possible (avec la rc7 en dernier). Mais voyons comment les choses évoluent au cours des prochaines semaines. En attendant, il y a beaucoup de corrections ordinaires ici et il nous faut encore plus de tests. Les statistiques de cette RC-5 sont franchement barbantes (ce qui est une bonne chose). Deux tiers de mises à jour des pilotes, 10 % de mises à jour d’architectures, 10 % sur les systèmes de fichiers, le reste en « divers ». Rien de frappant, sauf peut‐être à la prochaine réactivation [N. D. T. : l’option de compilation] de `-Wmaybe-uninitialized` dès que Arnd aura tout corrigé. Donc, allez‐y, testez. Linus ## RC-6 La version [RC-6](http://lkml.iu.edu/hypermail/linux/kernel/1611.2/03260.html) est sortie le dimanche 20 novembre 2016 : On avance dans la série des RC et, même si tout a été plutôt calme, je ne suis pas certain qu’on soit près du but. Il reste encore à corriger quelques problèmes qui n’ont rien à faire dans une RC-6, alors on va garder un œil là‐dessus. Il se pourrait qu’on ait une de ces sorties incluant une RC-8, ce qui, compte tenu de la taille de la 4.9, n’est peut‐être pas si inhabituel que ça. Cela dit, il n’y a rien de particulier qui ne me dérange vraiment. En revanche, nous avons des corrections de `VMALLOC_STACK` qui continuent d’arriver au compte‐gouttes et j’ai peur qu’on ne soit pas encore près d’en voir la fin. Aussi, attendons de voir à quoi la liste des régressions de Thorsten ressemblera la semaine prochaine. Donc, je n’ai pris encore aucune décision, d’un côté ou de l’autre, ça ira quand‐même. Que la RC-6 soit plus grosse que la RC-5 n’est pas particulièrement bon signe, en revanche. Mais, apparemment, tout ceci n’est que le reflet des fluctuations habituelles sur le rythme des sorties : la RC-6 avait des mises à jour réseau, mais pas la RC-5, par exemple. Il y a aussi quelques mises à jour de RDMA qui se démarquent. Rien de bien inquiétant. À part le réseau susmentionné et le RDMA, il y a des corrections au niveau des pilotes graphiques, un peu de corrections sur les outils et l’assemblage, plusieurs mises à jour sur les architectures (x86, PowerPC, ARM et Xtensa). Plus quelques corrections un peu partout (I2C, son, FUSE, KVM...). Allez‐y, testez. Linus ## RC-7 La version [RC-7](http://lkml.iu.edu/hypermail/linux/kernel/1611.3/02062.html) est sortie le dimanche 27 novembre 2016 : Toujours dans le cadre de l’agenda des sorties dominicales, voici la RC-7. Je pense que nous avons fait corriger tous les bêtes problèmes dont j’avais connaissance et, dans l’ensemble, les choses ont l’air d’aller plutôt bien. En fait, si la semaine prochaine se termine bien tranquillement, il se pourrait que cela soit la dernière RC, même si, honnêtement, je soupçonne fortement d’avoir à finir par une RC-8. C’est une grosse version et la RC-7 aurait pu être plus calme. On verra. Je me réserve le droit de me décider le week‐end prochain. Dans la RC-7, ce sont principalement les pilotes, l’architecture et le réseau qui ont été modifiés. En réalité, la plupart des mises à jour de pilotes concernent le réseau, je crois donc pouvoir dire « surtout des mises à jour de pilotes réseau et d’architectures, avec une poignée de mises à jour d’autres pilotes » (dans ces autres catégories de pilotes, on a notamment USB, pilotes graphiques, HID, I2C et [IOMMU](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit "Input‐output memory management unit")). Et l’on a toujours les trucs habituels un peu partout (le noyau, une correction eBPF, quelques corrections sur les systèmes de fichiers, etc.). Le sommaire des modifications ci‐joint donne une assez bonne vue sur ce qui a été fait. Linus ## RC-8 La version [RC-8](http://lkml.iu.edu/hypermail/linux/kernel/1612.0/02013.html) est sortie le dimanche 4 décembre 2016 : Alors, pour ceux qui auront suivi l’arborescence Git, ça ne devrait pas être une surprise si j’ai fini par faire une RC-8, en définitive : non pas que les choses aient mal tourné, mais ça n’a pas non plus été le calme plat qui m’aurait fait dire « _pas de quoi se taper encore une semaine_ ». Et les félicitations du jury pour Arnd, qui a fini par trouver la véritable cause de ces messages incroyablement pénibles « [_modversions_][1] ne fonctionnent pas avec les nouvelles versions de _binutils_ », en décortiquant les traces jusqu’à une modification bien précise dans la manière dont _binutils_ gère les symboles, puis en ajoutant un petit correctif d’une ligne au noyau pour contourner le problème. Nous avions déjà d’autres solutions en place, mais il est toujours bon de savoir exactement ce qui a changé dans la chaîne d’outils pour provoquer ce genre de chose. [1]: https://lwn.net/Articles/707520/ "Structures du noyau relatives à la gestion de la version des modules, apparemment en débat sur LWN." Cependant, cette ligne unique n’était qu’une des 163 petites corrections (sans compter les fusions) apportées à la RC-8. C’est assez petit (pour le noyau), mais pas complètement insignifiant. Tous les détails sur les modifications figurent au sommaire des modifications, mais c’est en majorité dans les pilotes réseau (des fuites dans la gestion des retours d’erreurs subsistent, mais la liste est disparate) et autres par‐ci, par‐là, avec en plus de petites corrections de trucs liés au noyau (mémoire virtuelle, systèmes de fichiers et noyau). Linus ## Version finale La version [finale](http://lkml.iu.edu/hypermail/linux/kernel/1612.1/01831.html) est sortie le dimanche 11 décembre 2016 : Ainsi, Linux 4.9 est sorti et, par conséquent, la fenêtre de fusion pour la 4.10 est ouverte. Avec la semaine supplémentaire prise par la 4.9, le calendrier de la période de fusion est évidemment un peu gênant et devrait techniquement se clôturer dans deux semaines, autrement dit le jour de Noël. Mais c’est une pure question de technique, parce que je vais certainement arrêter l’intégration le 23 au plus tard ; et, si je suis enrôlé dans les préparatifs du repas de Noël, même cette date pourrait être remise en question. Je pourrais étendre la fenêtre de fusion plutôt que de la raccourcir, mais je ne vais pas le faire. Je suppute que nous voulons tous une gentille pause d’hiver en paix ; donc, si vos affaires ne sont pas prêtes pour la fusion suffisamment tôt, la solution est bel et bien de ne pas les fusionner du tout et d’attendre la 4.11. Ceci pour que vous soyez tous au parfum (j’ai déjà averti la semaine dernière en message privé ceux que je suspecte de vouloir utiliser la fenêtre de fusion principale ; je me répète ici afin d’éviter la confusion à propos de l’agenda). Quoi qu’il en soit, revenons à la 4.9. Je suis sûr que c’est la plus grosse sortie que nous ayons jamais eue, au moins dans le nombre de modifications inscrites [N. D. T. : _commits_]. Si vous jetez un œil au nombre de lignes modifiées, nous avons eu des versions plus importantes dans le passé, mais elles avaient tendance à être dues à des problèmes spécifiques (par exemple, la version 4.2 a pris pas mal de lignes dans les fichiers de définition des registres des processeurs graphiques d’AMD et il y a eu de grosses restructurations ayant engendré un grand nombre de lignes par le passé : la version 3.2 était de grande taille en raison de la zone d’attente [N. D. T. : _staging_], la version 3.7 avait la [désintégration automatisée du fichier d’en‐tête uAPI](https://lwn.net/Articles/507794/), etc.). À côté, la 4.9 est juste énorme. Certes, la nouvelle prise en charge de [Greybus](https://kernel-recipes.org/en/2015/talks/an-introduction-to-greybus/) est un bon morceau, mais ce n’est vraiment pas le plus gros — c’est juste un autre petit détail dans l’ensemble « oui, la version 4.9 est une version importante ». En dehors de sa taille, la 4.9 semble plutôt normale. Un peu plus de deux tiers des pilotes (en gros la branche _staging_, les pilotes graphiques et réseau, mais il y en a partout), le reste aussi est plutôt normal : mises à jour d’architectures, documentation, infrastructure réseau générale, systèmes de fichiers... Le sommaire (plus de 16 000 modifications inscrites, ainsi qu’un autre lot de 1 100 fusions, pour arrondir le tout) est évidemment beaucoup trop volumineux pour être écrit ici ; ce serait illisible de toute façon. Donc, comme à mon habitude, j’ajouterai seulement le journal de mes fusions. Linus Sécurité ======== Pas de changement majeur du côté de la génération des nombres pseudo‐aléatoires ------------------------------------------------------------------------------- Contrairement à ce que laisse penser [_Phoronix_](https://www.phoronix.com/scan.php?page=news_item&px=LRNG-Linux-4.9-Patches), les [contributions de Stephan Müller](http://www.chronox.de/lrng.html) concernant son [« _Linux Random Number Generator_ »](https://lkml.org/lkml/2016/4/21/144) (LRNG) n’ont toujours pas été intégrées au noyau. Les rédacteurs de vos dépêches favorites vérifient scrupuleusement l’[historique](https://github.com/torvalds/linux/commits/master/include/linux/random.h) des [changements](https://github.com/torvalds/linux/commits/master/drivers/char/random.c) et ne se font pas avoir. Profitons‐en quand même pour présenter cette partie du noyau. :-) ### Réservoir d’entropie Afin d’obtenir le plus d’aléa (le plus d’entropie), le noyau collecte toutes les sources de *bruit* à sa disposition, généralement les variations infimes (le bit de poids faible) de différentes mesures. Voici quelques exemples : température (processeur, disque dur), heure d’arrivée des paquets réseau, [défaut de cache](https://fr.wikipedia.org/wiki/Mémoire_cache#Différents_types_de_défauts_de_cache_.28miss.29) *(cache miss)*, temps d’accès à la mémoire, [*ticks*](http://superuser.com/questions/101183/what-is-a-cpu-tick#101202). Le noyau a aussi à sa disposition des instructions spéciales du processeur. En revanche, ces instructions ne sont pas auditables (par un organisme indépendant) car les conception et fabrication des processeurs sont rarement accessibles. Et le noyau prend surtout en compte les sources d’entropie de confiance. ### Les fichiers /dev/urandom et /dev/random La lecture du fichier `/dev/urandom` génère un nombre pseudo‐aléatoire (_**u**niform **random**_) à partir du réservoir d’entropie. La lecture du fichier `/dev/random` génère aussi un nombre pseudo‐aléatoire, mais sa lecture reste bloquée tant que le noyau n’a pas collecté suffisamment de bruit. Un démon s’initialisant au démarrage du noyau va plutôt opter pour `/dev/urandom` pour éviter de se bloquer. Une application ayant besoin d’une garantie d’entropie sur un nombre aléatoire utilisera plutôt `/dev/random`. La fonction [`getrandom()`](http://man7.org/linux/man-pages/man2/getrandom.2.html) (en langage C) propose exactement ces mêmes services. ### Améliorations Stephan Müller avait proposé de rajouter 1 800 lignes de code source C pour changer la collecte d’entropie, dont les détails de conception et ses tests sont disponibles [en HTML](http://www.chronox.de/lrng/doc/lrng.xhtml) et [en PDF](http://www.chronox.de/lrng/doc/lrng.pdf). Ses principaux objectifs sont : * exploiter les SSD dans cette collecte d’entropie (on ne peut pas exploiter le réseau, car il n’est pas encore disponible) ; * exploiter les fonctions matérielles de génération pseudo-aléatoire ; * limiter par défaut les sources non auditables à un trente-deuxième du réservoir d’entropie ; * augmenter davantage l’entropie dès le démarrage et permettre la lecture du fichier `/dev/random` le plus tôt possible ; * améliorer l’entropie même dans une machine virtuelle ; * améliorer la performance sur les systèmes massivement multi‐cœurs et évitant les collectes d’entropie inutiles ; * permettre de tester de façon déterministe chacune des étapes ; * proposer une option (*switch*) de construction du noyau `CONFIG_CRYPTO_LRNG` pour choisir entre l’ancien et le nouveau fonctionnement (important pour les environnements avec peu de mémoire). ### Refus Ce sont surtout les agences nationales de sécurité informatique, comme l’[ANSSI](https://fr.wikipedia.org/wiki/ANSSI "Agence nationale de la sécurité des systèmes d’information") française, le [BSI](https://fr.wikipedia.org/wiki/Office_fédéral_de_la_sécurité_des_technologies_de_l'information "Bundesamt für Sicherheit in der Informationstechnik") allemand ou le [NIST](https://fr.wikipedia.org/wiki/NIST "National Institute of Standards and Technology") aux États‐Unis, qui sont intéressées par de telles améliorations. Mais elles n’apprécient pas les changements non audités... Allouer les piles d’exécution du noyau en mémoire virtuelle ----------------------------------------------------------- Les [contributions](https://github.com/torvalds/linux/commit/15f4eae70d365bba26854c90b6002aaabb18c8aa) (correctifs) d’Andy Lutomirski concernant les [fils d’exécution](https://fr.wikipedia.org/wiki/Thread_(informatique)) (_threads_) du noyau sont certainement celles que Linus a le plus appréciées, d’après son [message de la RC-1](#rc-1). Il faut dire qu’Andy vient de loin et a travaillé avec acharnement pour trouver des solutions radicales à tous les problèmes rencontrés et, au final, a joliment nettoyé les tréfonds du code source du noyau. Ce chapitre retrace cette aventure tumultueuse et se base sur les excellents articles de _LWN.net_ rédigés par Jonathan Corbet (juin 2016) et sous licence CC BY-SA 4.0 : * [_Virtually mapped kernel stacks_](https://lwn.net/Articles/692208/) * [_Virtually mapped stacks 2: thread_info strikes back_](https://lwn.net/Articles/692953/) ### Problème de conception Andy s’est attaqué au vieux problème de conception du noyau Linux des piles d’exécution (_call stacks_). Ces piles étaient toujours allouées directement en mémoire physique, avec des inconvénients ennuyeux. #### 1. Fragmentation Toute la pile doit tenir en un seul bloc de mémoire physique contigüe. Mais les grands blocs contigus sont de plus en plus difficiles à trouver au fur à mesure de la [fragmentation de la mémoire](https://fr.wikipedia.org/wiki/Fragmentation_(informatique)#Fragmentation_de_la_mémoire_vive). Ce qui met en péril un noyau Linux qui réalise de nombreuses opérations critiques depuis longtemps, surtout quand une attaque titille le noyau en le forçant à fragmenter sa mémoire. #### 2. Petite taille Pour réduire les risques de fragmentation, la taille des piles d’exécution est limitée généralement à 8 192 petits octets. Ce qui impose des contraintes strictes comme l’interdiction des appels récursifs, pas de structure passée par valeur et l’obligation d’analyser en détail les possibles enchaînements des appels de fonctions. Et de nombreuses personnes préféraient plutôt en avoir une plus grosse ! Même si parler de code récursif dans un noyau, cela fait froid dans le dos, car cela veut dire un risque de « _stack overflow_ » selon la taille des données traitées (et c’est mal) ! #### 3. Dépassement Malgré toute l’attention sur les arbres d’appel, les dépassements de pile (_stack overflow_) sont possibles. Une attaque peut trouver des combinaisons pour provoquer un dépassement et écraser des informations et même introduire son code exécutable. D’ailleurs, la taille a dû être doublée à 16 Kio sur les architectures [x64](https://fr.wikipedia.org/wiki/X64). #### 4. Contournements contre‐performants Pour détecter un dépassement, une solution consiste à positionner un [canari](https://fr.wikipedia.org/wiki/Canari_(homonymie)#Divers) à l’extrémité de la pile d’exécution. Ce canari correspond à une [valeur magique](https://fr.wikipedia.org/wiki/Nombre_magique_(programmation)) qui est vérifiée régulièrement afin de détecter son écrasement par une autre valeur et donc un dépassement de la pile d’exécution. Non seulement, cela oblige à réaliser des opérations supplémentaires (vérifier plus ou moins fréquemment), mais en plus, ce dépassement n’est détecté qu’_a posteriori_ et c’est souvent trop tard. Une seconde solution pour détecter un dépassement en mémoire physique consiste à rajouter une page mémoire en accès interdit. Mais cela gâche de la mémoire qui n’est pas utilisée et augmente le risque de fragmentation (le bloc de mémoire contigu doit être plus grand). Et que faire si le dépassement est détecté ? Tuer le fil d’exécution ou ré‐allouer une pile plus grande ? Avec la mémoire physique, tuer est plus facile que ré‐allouer. De plus, il faut utiliser une fonction [`realloc()`](https://fr.wikipedia.org/wiki/Malloc#realloc) différente, car la pile s’exécute de la fin vers le début, donc il faut ajouter de la mémoire avant et non après. Sans parler des risques d’augmentation de la fragmentation. ### Mémoire virtuelle L’idée initiale d’Andy était de proposer un agrandissement automatique de la taille de la [pile d’exécution](https://fr.wikipedia.org/wiki/Pile_d'exécution) au fur et à mesure que son dépassement est détecté en allouant cette pile en [mémoire virtuelle](https://fr.wikipedia.org/wiki/Mémoire_virtuelle). La gestion de la mémoire virtuelle a été un des tous premiers objectifs du noyau Linux avec le processeur [i386](https://fr.wikipedia.org/wiki/Intel_80386). C’est le [MMU](https://fr.wikipedia.org/wiki/Unit%C3%A9_de_gestion_m%C3%A9moire "Memory Management Unit — Unité de gestion de la mémoire") du processeur qui donne l’impression au fil d’exécution que la plage d’adresses est contigüe, mais les [pages](https://en.wikipedia.org/wiki/Page_(computer_memory)) de la mémoire physique (des blocs généralement de 4 Kio) peuvent être dispersées, réduisant considérablement les problèmes de fragmentation. Pour atteindre ce but ultime, Andy a remanié ses contributions à de très nombreuses reprises et son acharnement a abouti à des résultats spectaculaires non attendus. ### Trop lent Au tout début, le seul inconvénient de sa première proposition était une lenteur de **1,5 μs** lors de la création d’un nouveau fil d'exécution du noyau. Ce temps d’exécution plus long est imputable à la fonction `vmalloc()` utilisée pour allouer de la mémoire à la pile d’exécution (_**v**irtual **m**emory **alloc**ation_ — allocation de mémoire virtuelle). Cette fonction prend plus de temps, car elle réalise des opérations supplémentaires et n’a pas bénéficié du même effort d’optimisation que les autres fonctions d’allocation. Mais, pour Linus, cette régression de performance est irrecevable. ### Mémoire tampon Alors, voyons comment éviter d’appeler la fonction `vmalloc()`. Pour cela, Linus a demandé à Andy de recycler les piles d’exécution des derniers fils s’étant terminés. On les conserve temporairement dans une petite mémoire tampon et on les fournit dès qu’il faut créer un nouveau fil d’exécution. Cela devrait nous permettre d’appeler `vmalloc()` moins souvent. ### Incompatibilité avec le Read‐Copy‐Update Mais, c’est oublier le fonctionnement fourbe du [*Read‐Copy‐Update*](https://en.wikipedia.org/wiki/Read-copy-update) (RCU) qui libère les ressources d’un fil d’exécution (dont sa pile d’exécution) par saccade. Le RCU accumule les ressources de tous les fils d’exécution qui se terminent, puis les libère tous en même temps. Notre petit cache de piles d’exécution se retrouve donc à devoir absorber plus de piles d’exécution qu’il ne peut en contenir. Et, en attendant le prochain cycle du RCU, nous nous retrouvons rapidement avec un cache vide et donc la nécessité d’appeler la fonction `vmalloc()`. ### Contournement du *Read-Copy-Update* Au lieu d’augmenter la capacité de notre cache (pensons aux systèmes avec peu de mémoire), essayons de décorréler la pile d’exécution du mécanisme RCU. En récupérant nous‐même la pile d’exécution d’un fil qui se termine, nous évitons les pics de piles d’exécution fournis par le RCU. En revanche, le RCU libère les autres ressources du fil d’exécution à son rythme. ### Interdépendance entre la mémoire de la pile et le *Read‐Copy‐Update* Mais, nous avons un autre problème : la pile d’exécution et les autres ressources du fil d’exécution ne sont pas complètement décorrélées. En fait, les informations du fil d’exécution sont dispersées à deux endroits : 1. dans la structure `task_struct`, qui est allouée indépendamment de la pile d’exécution (*ouf*) ; 2. dans la structure `thread_info`, qui fait partie du même bloc mémoire que la pile d’exécution (*zut*). C’est là que les choses se compliquent : les différentes parties du noyau ne vont pas immédiatement être au courant qu’un fil d’exécution vient de se terminer, cela prend un certain temps pendant lequel la structure `thread_info` ne peut être utilisée par un nouveau fil d’exécution. On en revient au même : attendre la fin du cycle du RCU ! ### Se débarrasser du `thread_info` Et si nous déplacions le `thread_info` ailleurs ? Eh bien, c’était comme cela au début du noyau, tout était dans `task_struct`. Mais avoir quelques informations directement dans le même bloc mémoire que la pile d’exécution permet justement d’éviter une indirection. D’ailleurs, c’est l’essence même de l’existence de `task_struct` : permettre un accès direct en appliquant un masque sur le pointeur d’exécution (`$sp`). Avec le temps, la structure `task_struct` contient les champs génériques, indépendants de la plate‐forme (_architecture‐independent_). Et la structure `thread_info` contient les champs spécifiques à la plate‐forme (_architecture‐specific_). Pourtant, ces dernières années, la structure `thread_info` a fondu. Quelques champs de cette structure ont été déplacés dans une structure de données spécifique à chaque [cœur](https://fr.wikipedia.org/wiki/Microprocesseur_multi-cœur) (unité de calcul). Mais, ce n’est pas là non plus que nous pouvons déplacer des champs de `thread_info`, car seul le code s’exécutant sur ce cœur a le droit d’accéder à sa structure de données spécifique, afin d’éviter que le processeur perde du temps à [synchroniser les caches mémoire de niveau 2](https://fr.wikipedia.org/wiki/Protocole_de_coh%C3 %A9rence_de_cache). C’est là que Linus a donné un coup de main à Andy. D’abord, en réduisant la dépendance entre les différentes parties du noyau vis‐à‐vis de la structure `thread_info`. Puis, en déplaçant certains champs vers `task_struct`. Andy a poursuivi ce travail pour chaque champ. Et le dernier champ contenant les drapeaux (_flags_) a également été déplacé vers `task_struct`. Mais cela demande tellement d’investissement sur chaque plate‐forme spécifique, qu’Andy a mené à bien ce travail uniquement pour la plate‐forme x86. ### C’est gagné ! Maintenant, nous avons enfin la mémoire de la pile d’exécution qui peut être directement libérée dès la fin du fil d’exécution, sans avoir besoin d’attendre la fin du cycle RCU. Et nous pouvons donc mettre en cache cette pile d’exécution dans la structure de données spécifique à chaque cœur. Les avantages de la contribution d’Andy sont nombreux : #### 1. Gain en performance En faisant des tests avec un petit cache pour deux piles d’appel, la latence de 1,5 μs se transforme en un gain de performance entre 1⁄2 et 1 μs. #### 2. Détection immédiate du dépassement de la pile d’exécution En plus de ce gain de performance, nous avons aussi un dépassement de la pile (_stack overflow_) qui est immédiatement détecté. Avant, le dépassement de la pile commençait par écraser la structure `thread_info`, ce qui ne pouvait pas être détecté (car cela ne dépassait pas le bloc mémoire). D’ailleurs, c’était une faille de sécurité importante. En faisant exécuter par le noyau un long enchaînement de fonctions, on pouvait changer les valeurs dans `thread_info`. #### 3. Meilleur diagnostic Et, comme en cas de dépassement de pile, les informations de `thread_info` ne sont plus écrasées, il est plus facile de diagnostiquer le problème et ce, sans planter le noyau. Le dépassement est détecté, le noyau arrête le fil d’exécution et fournit un rapport d’erreur complet et précis. ### Plébiscite Devant l’avalanche de tels avantages, dont le nettoyage/regroupement des informations des fils d’exécution, les autres architectures sont en train d’être adaptées afin de ne plus avoir le `thread_info` dans le même bloc mémoire que la pile d’exécution. En conclusion, cette épopée dans les entrailles du code source du noyau a permis de belles réalisations et Andy va pouvoir reprendre son idée initiale d’agrandir automatiquement la taille de la pile d’exécution en détectant son dépassement mémoire. Le noyau pourrait avoir à l’avenir des petites piles d’exécution pour la grande majorité des cas. Et pour une minorité de cas, la taille de la pile s’adaptera dynamiquement sans avoir à tuer le fil d’exécution. C’est un très bon compromis entre économie de mémoire et sécurité accrue. Merci Andy Lutomirski et bonne continuation dans ton formidable travail. [![Visage d’Andy Lutomirski](https://oasis.sandstorm.io/logos/luto.png)](https://oasis.sandstorm.io/about) Clefs de protection de la mémoire (memory protection keys) ---------------------------------------------------------- Cette nouvelle fonctionnalité abrégée _pkeys_ permet d’empêcher que d’autres processus accèdent à des plages d’adresses. C’est le rêve des cryptographes : cacher ses secrets. Cette technologie existait déjà sur les bons vieux ordinateurs centraux — _mainframes_ — ([*Key‐controlled memory protection*](https://en.wikipedia.org/wiki/IBM_System/360#Architectural_overview)). Et voilà qu’Intel l’intègre depuis le [Skylake pour serveur](https://fr.wikipedia.org/wiki/Skylake#Processeurs_pour_serveur) (commercialisé depuis un an). [Dave Hansen](https://www.linkedin.com/in/dave-hansen-5b3727a) (Intel) avait proposé une prise en charge, mais elle a été refusée pour la [version 4.6](http://phoronix.com/scan.php?page=news_item&px=Linux-4.6-MPK-PKeys). Puis améliorée, mais encore refusée pour la 4.7. Et, rebelote pour la 4.8. La contribution de Dave Hansen a enfin été acceptée pour la 4.9, au bout de la [sixième révision](https://lkml.org/lkml/2016/8/8/809). ### API Nous avons maintenant ces nouvelles fonctions dans l’API du noyau : ```c int pkey_alloc(unsigned long flags, unsigned long init_access_rights) int pkey_free(int pkey); int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey); ``` Dans les précédentes révisions de cette contribution, il y avait deux autres fonctions. Nous les signalons pour éviter que nos lecteurs se trompent en se basant sur des documentations obsolètes. Dave Hansen a récemment [nettoyé leurs traces du noyau](https://lkml.org/lkml/2016/10/18/427) : ```c /* Fonctions supprimées */ unsigned long pkey_get(int pkey); int pkey_set(int pkey, unsigned long access_rights); ``` Ces nouvelles fonctions permettent donc de protéger en **écriture seulement** ou en **lecture et écriture** des adresses mémoire. Attention, l’implémentation sous‐jacente d’Intel peut être contournée, car les nouvelles instructions ajoutées, `RDPKRU` et `WRPKRU`, peuvent être utilisées par d’autres fils d’exécution. ### Voir aussi Toutes ces documentations sont en langue anglaise. Si les lectrices et lecteurs de *LinuxFr.org* souhaitent lire une dépêche en français sur ce sujet, merci de nous le signaler dans les commentaires. Les excellents articles de Jonathan Corbet (CC BY-SA 4.0) publiés sur _LWN.net_ : * [_Memory protection keys v5_](https://lwn.net/Articles/667156/) (décembre 2015) ; * [_Memory protection keys_](https://lwn.net/Articles/643797/) (mai 2015) ; * [_System calls for memory protection keys_](https://lwn.net/Articles/689395/) (juin 2016) ; * [_Memory protection keys pushback_](https://lwn.net/Articles/695355/) (juillet 2016) ; * [`Documentation/x86/protection-keys.txt`](https://lwn.net/Articles/703208/) (octobre 2016). Manuel de l’API Linux : * [_Overview of Memory Protection Keys_](http://man7.org/linux/man-pages/man7/pkeys.7.html) ; * [`pkey_alloc()` et `pkey_free()`](http://man7.org/linux/man-pages/man2/pkey_alloc.2.html) ; * [`mprotect()` et `pkey_mprotect()`](http://man7.org/linux/man-pages/man2/pkey_mprotect.2.html). Couches bas niveau : * [fonctionnalités de sécurité du processeur Intel](https://github.com/huku-/research/wiki/Intel-CPU-security-features#protection-keys-pdf) ; * [manuel du développeur des architectures Intel 64 et IA-32 (vol. 3A)](http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html) (lire §4.6.2). Pilotes graphiques libres ========================= AMD --- ![Logo AMD](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/AMD_Logo.svg/220px-AMD_Logo.svg.png) Le nouveau pilote graphique libre _amdgpu_ pour les cartes graphiques AMD [GCN](https://en.wikipedia.org/wiki/Graphics_Core_Next "Graphics Core Next") a été mis à jour et introduit la prise en charge de l’affichage virtuel. Son contenu est ensuite accessible via un logiciel de bureau à distance. Autre changement apporté par ce pilote, la prise en charge de la technologie de réduction de consommation énergétique [AMD PowerPlay](https://en.wikipedia.org/wiki/AMD_PowerPlay) pour les cartes graphiques équipées d’un processeur graphique de génération _Iceland_ (2014). L’amélioration de la réinitialisation des unités de calcul accéléré ([APU](https://fr.wikipedia.org/wiki/Accelerated_processing_unit "Accelerated Processing Unit")) de génération _Carrizo_ (2015), ainsi que de son remplaçant _Stoney Ridge_ (2016). La prise en charge des circuits intégrés spécialisés ([ASIC](https://fr.wikipedia.org/wiki/Application-specific_integrated_circuit "Application‐Specific Integrated Circuit")) AMD UVD (_Unified Video Decoder_), permettant le décodage vidéo, et AMD VCE (_Video Coding Engine_), qui permet le codage des normes vidéo de type H.264, MPEG-2, MPEG-4 et VC-1, a été ajoutée pour les puces plus récentes. Prise en charge également de la pré‐initialisation de la mémoire tampon de la VRAM, par exemple, la remise à zéro. Et de nombreuses autres corrections de bogues en tout genre. Voir aussi : - [[Phoronix] _The Exciting Features Of The Linux 4.9 Kernel_](http://www.phoronix.com/scan.php?page=article&item=linux-49-features&num=1) ; - [[Phoronix] _AMDGPU Patches For Virtual Display Feature_](http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Virtual-Display) ; - [[pull] _radeon and amdgpu drm-next-4.9_](https://lists.freedesktop.org/archives/dri-devel/2016-August/116640.html). ## Nouveau Aucun changement pour le pilote _nouveau_ n’a été intégré à cette version du noyau. Réseau ====== BBR --- Le protocole [TCP](https://fr.wikipedia.org/wiki/Transmission_Control_Protocol "Transmission Control Protocol") est l’un des plus utilisés sur Internet. Il est, entre autres, utilisé par HTTP et SSH. L’un des atouts de ce protocole est sa capacité à gérer la congestion, c’est‐à‐dire, sa capacité à continuer de fonctionner quand le réseau commence à être saturé par les connexions. En effet, lorsque l’on augmente le trafic sur un réseau, le temps d’attente dû à des interblocages augmente (sur Ethernet, il n’y a qu’une seule trame à la fois, par exemple). TCP est capable de réduire son débit automatiquement pour réduire cette congestion. Depuis la création de TCP, différents algorithmes ont vu le jour pour améliorer le débit, car les premières versions ne pouvaient pas atteindre les 100 Mbit/s, par exemple. Le BBR (pour _Bottleneck Bandwidth and RTT_) fait donc suite aux douze autres protocoles permettant à TCP de réduire son débit lorsque le réseau est congestionné tout en maximisant les débits (dans les cas sans congestion et lors de la congestion). Il faut comprendre que ces algorithmes ont différentes propriétés. D’une part, on cherche à ce qu’ils soient le plus efficace possible pour améliorer le débit utile par rapport à l’ensemble du débit consommé, ensuite, il y a différentes façons de se comporter lors de la congestion. Par exemple, le débit peut augmenter plus ou moins vite une fois la congestion passée. La meilleure solution dépendra (entre autres) des couches inférieures du réseau (comme le lien physique) et des autres équipements. C’est ce qui explique qu’il y ait encore tant d’algorithmes différents pour répondre à la même problématique. Ce nouvel algorithme a été proposé par une équipe de Google. Ces derniers expliquent que BBR, contrairement aux autres algorithmes, ne se base pas sur des pertes de paquets, mais sur des mesures faites au fur et à mesure. Ainsi, il n’attend pas d’être dans les pires cas pour ajuster son débit. Ils expliquent aussi que cet algorithme est déjà utilisé dans les infrastructures de [YouTube](http://www.youtube.com) et de [Google Search](http://www.google.com) (excusez du peu). Un des premiers [tests](http://blog.cerowrt.org/post/bbrs_basic_beauty/) publics qui compare l’algorithme TCP Reno, TCP CUBIC et TCP BBR semble montrer de bons résultats. * [[_LWN_] _BBR congestion control_](https://old.lwn.net/Articles/701165/) ; * [[_Wikipédia_] _Algorithme TCP_](https://fr.wikipedia.org/wiki/Algorithme_TCP) ; * [[_CeroWrt notebook_] _A quick look at TCP BBR_](http://blog.cerowrt.org/post/bbrs_basic_beauty/) ; * [[_ozlabs.org_] _[net-next,14/14] tcp_bbr: add BBR congestion control_](https://patchwork.ozlabs.org/patch/671069/) ; * [[_Wikipédia_] _Congestion réseau_](https://fr.wikipedia.org/wiki/Congestion_(r%C3%A9seau)) ; * [[_Wikipédia_] _Transmission Control Protocol_](https://fr.wikipedia.org/wiki/Transmission_Control_Protocol) ; * [[_BBR Development_] _BBR Congestion Control Development_](https://groups.google.com/forum/#!forum/bbr-dev) ; * [[_git.kernel.org_] _tcp_bbr: add BBR congestion control_](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f8782ea14974ce992618b55f0c041ef43ed0b78). Systèmes de fichiers ==================== FUSE ---- [FUSE](https://fr.wikipedia.org/wiki/Filesystem_in_Userspace) (pour _Filesystem in Userspace_) a été mis à jour. Il permet à un utilisateur sans privilèges particuliers d’accéder à un système de fichiers, sans qu’il soit nécessaire de modifier les sources du noyau. Il est utilisé dans GNOME ([GVfs](https://wiki.gnome.org/Projects/gvfs)), pour écrire sur des partitions NTFS ([NTFS-3G](http://www.tuxera.com/community/open-source-ntfs-3g/)), par [VeraCrypt](https://veracrypt.codeplex.com/), ou encore [Flatpak](http://flatpak.org/). Le [correctif](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/01531.html) de FUSE apporte enfin [la vérification des permissions](http://www.phoronix.com/scan.php?page=news_item&px=FUSE-POSIX-ACLs-Linux-4.9) ([ACL](https://fr.wikipedia.org/wiki/Access_Control_List)) [POSIX](https://fr.wikipedia.org/wiki/POSIX "Portable Operating System Interface — interface portable de système d’exploitation"), ainsi que diverses corrections de bogues. Ceux qui souhaitent découvrir ce que sont les listes de contrôle d’accès POSIX sous Linux peuvent lire [l’article (en anglais) qui leur est dédié](http://www.vanemery.com/Linux/ACL/POSIX_ACL_on_Linux.html). Lire aussi [la version française sur Wikipédia](https://fr.wikipedia.org/wiki/Permissions_UNIX) de leur mise en œuvre sous UNIX. ## UBIFS Un correctif proposé par Bean Huo introduit la [gestion d’OverlayFS](http://lists.infradead.org/pipermail/linux-mtd/2016-May/067371.html). Pour ceux qui se servent d’[UBIFS](https://fr.wikipedia.org/wiki/UBI_File_System "Unsorted Block Images File System") sur de la mémoire Flash brute, il n’existe pas, en ce moment, de prise en charge d’OverlayFS. Néanmoins [le travail est en préparation](http://www.phoronix.com/scan.php?page=news_item&px=UBI-UBIFS-Linux-4.9) pour les mémoires Flash de type [MLC NAND](https://fr.wikipedia.org/wiki/Cellule_multi-niveaux) (mémoires Flash NAND à cellules multi‐niveaux). ## ext4 [Corrections et nettoyages](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/02733.html), notamment dans la gestion des attributs étendus. ## Btrfs Correction de bogues et diverses optimisations. Rien d’excitant pour le moment. Chris Mason signale d’ailleurs que [des modifications plus importantes sont en préparation pour la version 4.10](http://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Changes-Linux-4.9). ## F2FS [F2FS](https://fr.wikipedia.org/wiki/F2FS "Flash-Friendly File System — Système de fichiers adapté à la mémoire Flash"), le système de fichiers de Samsung dédié à la mémoire Flash, a reçu plusieurs améliorations : * l’option `inline_dentry` est désormais activée par défaut, ce qui devrait [améliorer l’utilisation de l’espace disque et les performances](http://www.phoronix.com/scan.php?page=news_item&px=EXT4-F2FS-Linux-4.9) pour les systèmes de fichiers avec beaucoup de petits répertoires ; * F2FS peut maintenant préallouer des blocs pour les fichiers chiffrés. La commande [`trim`](https://fr.wikipedia.org/wiki/Trim_(informatique)) a également reçu quelques améliorations. ## XFS [XFS](https://fr.wikipedia.org/wiki/XFS), le système de fichiers hérité d’[IRIX](https://en.wikipedia.org/wiki/IRIX), l’UNIX de [SGI](https://fr.wikipedia.org/wiki/Silicon_Graphics "Silicon Graphics Inc."), s’est vu ajouter un nombre important de fonctionnalités, notamment à son infrastructure, mais aussi au format des données. Suite aux [contributions soumises par Dave Chinner](http://lkml.iu.edu/hypermail/linux/kernel/1610.1/01939.html), un espace disque peut désormais avoir [plusieurs propriétaires](http://www.phoronix.com/scan.php?page=news_item&px=XFS-Linux-4.9-Shared-Extents) (_XFS Shared Extents_ ou zones disque partagées), ceci grâce à l’adjonction, dans chaque groupe d’allocation, d’un nouvel [arbre B](https://fr.wikipedia.org/wiki/Arbre_B) (B‐tree) répondant au doux nom de _refcount_. Prise en charge des plates‐formes ================================= Raspberry Pi Zero ----------------- La gestion du [Raspberry Pi Zero](http://raspbian-france.fr/raspberry-pi-zero-5-euros/) a été ajoutée en même temps que d’autres systèmes mono‐puces de Broadcom. Amlogic S905 ------------ La prise en charge de l’Amlogic S905 a été améliorée. La gestion des systèmes mono‐puces ARM 64 bits d’Amlogic fait l’objet d’un gros travail depuis Linux 4.7. On a en plus grâce à Linux 4.9, notamment : - [PWM](https://fr.wikipedia.org/wiki/Modulation_de_largeur_d'impulsion "Pulse Width Modulation") (modulation en largeur d’impulsions), pierre angulaire de la gestion du Wi‐Fi sur les cartes Amlogic ; - la Mailbox, utilisée pour la communication [SCPI](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922g/index.html) qui gère le [DVFS](https://en.wikipedia.org/wiki/Dynamic_voltage_scaling "Dynamic voltage scaling") (adaptation dynamique de la tension d’alimentation et de la fréquence d’un micro‐processeur) ; - l’[I2C](https://fr.wikipedia.org/wiki/I2C "Inter‐Integrated Circuit") et le [SPI](https://fr.wikipedia.org/wiki/Serial_Peripheral_Interface "Serial Peripheral Interface") ; - des améliorations de l’Ethernet 10, 100 et 1000 Mbit/s. La gestion de MMC/SD/SDIO, [SCPI](https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments "Standard Commands for Programmable Instruments") et de l’USB est malheureusement repoussée pour Linux 4.10. Cette dernière intégrera le Wi‐Fi (si les pilotes [SDIO](https://en.wikipedia.org/wiki/Secure_Digital#SDIO "Secure Digital Input Output") sont dans Linux) et les variantes S905D, S905X et S912. Autres ------ On voit également débarquer la prise en charge de diverses plates‐formes et composants : - ZTE ZX296718, SoC ARM 64-bit ; - les systèmes mono‐puces Broadcom BCM47189 et BCM53573, premiers systèmes mono‐puces ARM à se conformer au standard Wi‐Fi 802.11ac. ; - Renesas r8a7796 (R-Car M3-W), système mono‐puce pour l’automobile ; - le NextThing GR8, très proche de celle du A13/R8 ; - la platine de développement Marvell Armada 8040 avec son Cortex-A72 à quatre cœurs et ses trois interfaces Ethernet 10 Gbit ; - la carte Qualcomm DragonBoard 820c 96Boards ; - TVBox Tronsmart Orion r86, une carte pour boîtiers décodeurs avec un système mono‐puce octocœur Rockchip RK3368 ; - Qualcomm External Bus Interface 2 (EBI2), utilisé sur les téléphones pour connecter la mémoire Flash, les écrans LCD et d’autres périphériques ; - les cartes Allwinner, incluant l’Empire Electronix M712 et la tablette iNet D978 rev2, ainsi que l’[Orange Pi PC Plus](http://www.orangepi.org/orangepipcplus/), [Orange Pi 2](http://www.orangepi.org/orangepi2/), [Orange Pi Plus 2E](http://www.orangepi.org/orangepiplus2/), [Orange Pi Lite](http://orangepi.com/orange-pi-lite), [Olimex A33-Olinuxino](https://www.olimex.com/Products/OLinuXino/A33/A33-OLinuXino/open-source-hardware) et le [Nano Pi Neo](http://nanopi.io/nanopi-neo.html) ; - les cartes Broadcom incluant les cartes de références BCM958525er, BCM958522er, BCM988312hr, BCM958623hr et BCM958622hr ; - le routeur NETGEAR WNR854T ; - le [LG Nexus 5](http://www.lg.com/fr/smartphones/lg-Nexus-5-smartphone) ; - la Beagleboard-x15 rev B1 ; - la conversion vers l’arborescence matérielle DeviceTree pour _mach-omap2_ est complète, incluant une gestion complète du vénérable Nokia N900. Autres nouveautés ================= Pilote de test EFI ------------------ Ce pilote, [soumis par Ingo Molnar](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00387.html), mais dont Canonical assure la maintenance, [est désormais inclus dans le noyau](http://www.phoronix.com/scan.php?page=news_item&px=EFI-Test-Driver-Linux-4.9) dans le but d’aider les développeurs de micrologiciels (_firmwares_). Il exporte en espace utilisateur les interfaces du service d’exécution UEFI et est utilisé par la suite de test de micrologiciels (FTWS). Plate‐forme Mellanox -------------------- Un [correctif, également proposé par Ingo Molnar](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/00480.html), marque le [début de la prise en charge de la plate‐forme Mellanox](http://www.phoronix.com/scan.php?page=news_item&px=Mellanox-Linux-4.9), utilisée principalement dans les domaines du calcul à haute performance et les centres de traitement de données (_data centers_). Ces plates‐formes ne sont pas données, par exemple, le commutateur réseau MSX6710 à 36 ports coûte la bagatelle de 11 900 US$. Mellanox est un fournisseur de matériel haut de gamme [[InfiniBand]] et Ethernet pour serveurs et plates‐formes de stockage en masse. MD RAID ------- Le code de MD [RAID](https://fr.wikipedia.org/wiki/RAID_%28informatique%29 "Redundant Array of Independent Disks — regroupement redondant de disques indépendants") ajoute la prise en charge de AXV512 pour accélérer le RAID 6 [et d’autres améliorations](http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-MD-RAID) pour la création d’un volume. NVDIMM ------ Le code NVDIMM ajoute plus de flexibilité dans la prise en charge de ces zones de mémoire non volatile exportées par ACPI. Michael Larabel en écrit un [bref récapitulatif](http://www.phoronix.com/scan.php?page=news_item&px=NVDIMM-Linux-4.9) sur son site, [_Phoronix_](http://www.phoronix.com). Intel Integrated Sensor Hub (ISH) --------------------------------- Linux 4.9 prend également en charge le [module ISH](http://www.phoronix.com/scan.php?page=news_item&px=Intel-ISH-HID-Linux-4.9) (_Integrated Sensor Hub_) d’Intel, un capteur intégré en remplacement de capteurs externes. Ces capteurs détectent, par exemple, le changement de position de l’appareil, contribuent à l’ajustement automatique de la luminosité et interviennent également dans la gestion de l’énergie sur les ordinateurs portables. Ce correctif est destiné à la famille de processeurs [_Cherry Trail_](http://ark.intel.com/products/codename/46629/Cherry-Trail) et suivantes. Intel Atom ---------- Un [nouvel algorithme](https://lkml.org/lkml/2016/10/14/288) de gestion du _P-state_ (une collection de niveaux prédéfinis pour la gestion de l’énergie) a été soumis par Rafael J. Wysocki. En outre, il [améliore les performances](http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-Atom-P-State-Algo) des processeurs Intel Atom en baissant moins fortement le niveau d’énergie. L’idée est d’ajouter 50 % à l’objectif de performance calculé pour diminuer le coût de migration d’un processus vers un autre cœur. Projet ARA de Google -------------------- Le pilote qui gère Greybus, conçu sur les bases du protocole [UniPro](https://en.wikipedia.org/wiki/UniPro), a été ajouté au noyau Linux. ### Unipro ? UniPro est un protocole de communication, comme [I2C](https://fr.wikipedia.org/wiki/I2C "Inter‐Integrated Circuit"), destiné à l’interconnexion de divers circuits intégrés. Il est destiné à être utilisé dans le monde des ordiphones. ![UniPro](https://upload.wikimedia.org/wikipedia/commons/8/88/UniPro_network.png) Il est notamment utilisé par Google pour son projet [ARA](https://atap.google.com/ara/) qui vise à créer un ordiphone modulaire. On peut le retrouver dans un produit grand public commercialisé : le téléphone Lenovo Moto Z utilise ce bus pour ses Moto Mods. Les différentes versions du protocole UniPro ont été créées par la [MIPI Alliance (_Mobile Industry Processor Interface Alliance_)](http://mipi.org/) composée de 250 entreprises. Le protocole a été créé en 2006. Unipro est un protocole de transmission à haute vitesse et de faible consommation électrique. Il prend en charge jusqu’à 128 périphériques. Il respecte les standards de l’[OSI](https://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI "Open Systems Interconnection"). ### Greybus ? Greybus est une couche applicative pour UniPro ce qui correspond à la septième couche du modèle OSI. C’est un bus générique initialement transporté sur USB, avec des notions de « _cports_ » et de liens logiques correspondants aux liens UniPro, mais il a été conçu pour ne pas être dépendant du lien physique. L’implémentation dans Linux suppose une communication avec un « SVC » qui, dans le téléphone ARA, est un microcontrôleur utilisé pour gérer le routage des liens logiques vers les _cports_ des périphériques UniPro. Il y a par exemple des implémentations 100 % USB avec un démultiplexage des _cports_ dans un micrologiciel sur un STM32F4 ou, plus récemment, une implémentation d’un routage Greybus en espace utilisateur via Netlink, et une communication par Bluetooth avec des modules. Cela donne en pratique des interfaces virtuelles locales vers des périphériques distants. Par exemple, GreyBus permettait d’exposer le bus I2C ou SPI des modules et de les contrôler avec les API I2C ou SPI de Linux, ou même d’y associer des pilotes classiques. UniPro, quant à lui, se situe au niveau de la couche physique, soit la première couche du modèle OSI. Ci‐dessous la mise en œuvre de Greybus dans le noyau Linux : ![Intégration de Greybus dans le noyau Linux](http://www.modularphonesforum.com/wp-content/uploads/2015/02/part36_structure.jpg) Voir aussi : - [[_modular phones forum_] _Greybus protocol – an application layer for UniPro. Project Ara Developers Conference (January 2015, Singapore). Part 3.6._](http://www.modularphonesforum.com/news/greybus-protocol-an-application-layer-for-unipro-491/) ; - [[_Wikipédia_] _UniPro_](https://en.wikipedia.org/wiki/UniPro) ; - [[_kernel-recipes.org_] _An Introduction to Greybus_](https://kernel-recipes.org/en/2015/talks/an-introduction-to-greybus/) ; - [[_Wikipédia_] _MIPI Alliance_](https://en.wikipedia.org/wiki/MIPI_Alliance) ; - [[MIPI Alliance] _UniPro(SM) Specifications_](http://mipi.org/specifications/unipro-specifications). Commande perf ------------- Parmi les améliorations apportées à l’outil en ligne de commande `perf`, on peut lister la gestion de fichiers [JSON](https://fr.wikipedia.org/wiki/JavaScript_Object_Notation "JavaScript Object Notation — Notation object JavaScript") pour décrire les évènements de l’unité de supervision des performances (PMU — _Performance Monitor Unit_), un nouvel ensemble d’astuces et le début du travail pour la gestion de Clang/LLVM [_demande d’intégration_](http://lkml.iu.edu/hypermail/linux/kernel/1610.1/00092.html). KThread ------- L’API KThread a reçu un gros coup de nettoyage. Clef de protection mémoire -------------------------- Attendue depuis un moment, la nouvelle interface MPK (_Memory Protection Keys_ ou clefs de protection de la mémoire) est maintenant terminée et intégrée à Linux 4.9, d’après le [correctif envoyé par Thomas Gleixner](http://lkml.iu.edu/hypermail/linux/kernel/1610.1/00101.html). Ce système définit un ensemble d’interfaces en espace utilisateur (lire _des appels système_) et offre aux applications un mécanisme de protection des données par page, à l’aide de clefs de chiffrement. Cette protection sera [mise en application dans les futurs processeurs de la firme Intel](http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.6-MPK-PKeys). On peut lire, sur le site _Phoronix_, [comment la mettre en œuvre](https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-Mem-Protection-Keys) en langage C. Virtualisation Xen et KVM ------------------------- La plate‐forme de virtualisation Xen a reçu un [correctif](http://lkml.iu.edu/hypermail/linux/kernel/1610.0/02435.html) qui introduit une fonctionnalité fort intéressante : [les connexion et déconnexion à chaud du processeur](http://www.phoronix.com/scan.php?page=news_item&px=Xen-KVM-Linux-4.9) (c.‐à‐d. pendant que la machine fonctionne) — sur les cartes‐mères qui en possèdent plus d’un, bien entendu. Quant à KVM, autre plate‐forme de virtualisation, ce sont des améliorations sur l’architecture ARM qui ont été apportées. À noter également un travail préparatoire sur l’adressage virtuel étendu ([EVA](https://www.linux-mips.org/wiki/Enhanced_Virtual_Addressing "Enhanced Virtual Addressing")) pour les processeurs MIPS. Virtual mapped stack -------------------- Andy Lutomirski a introduit un nouveau mécanisme de gestion des piles noyau, qui a pour effet secondaire d’[optimiser la création de tâches par la mise en cache de deux piles de fil d’exécution par processeur](https://lkml.org/lkml/2016/9/16/178). Initialement, ce correctif a pour but de faciliter le diagnostic et de sécuriser l’interception des débordements de pile, ce qui devrait aussi rendre leur exploitation (_exploit_) plus difficile. Une pile virtuelle est encadrée par des pages de garde et les débordements sont interceptés immédiatement par le noyau, au lieu de provoquer des corruptions mémoire extrêmement difficiles à diagnostiquer. Ce genre de fonctionnalités était fourni par les correctifs de [[grsecurity]]. Lire également les articles sur les sites [_Phoronix_](http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-x86-ASM-Vmap-Stack) et [_LWN.net_](https://lwn.net/Articles/692208/). Statistiques ============ Entreprises ayant participé à cette version ------------------------------------------- ### En nombre de lignes changées AMD sort en première position avec 105 820 lignes modifiées soit 11,1 % du total de lignes modifiées, suivie de très près par Red Hat avec 104 492 lignes, soit 10,9 %. Intel s’en sort en troisième positon avec 89 456 lignes, soit 9,4 % du total (_cf._ l’article de Jonathan Corbet [_Development statistics for 4.9_](https://lwn.net/Articles/708266/) sur _LWN.net_).

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