Sortie du noyau Linux 4.2

La sortie de la version stable 4.2 du noyau Linux a été annoncée le 30 août 2015 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 (qui est sous licence CC BY-SA, Attribution - Partage dans les Mêmes Conditions).

Sommaire

• Annonces des RC par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • RC-8
  • Version finale
• Liste des nouveautés
  • Architecture
    • Systèmes monopuces ARM
    • Renesas H8/300
    • ARCv2, HS38 CPU Cores
  • Général
    • Amélioration des verrous
    • Amélioration de l’ordonnanceur
    • Le nettoyage du code d’assemblage continue
    • Plus de limite pour une suite de liens symboliques
    • L’appel système splice et les sockets Unix
    • Control group write back
  • Développeurs
    • Amélioration de l’outil perf
  • Pilotes graphiques libres
    • Direct Rendering Manager
    • AMD/ATI
      • Pilote de rendu nouvelle génération (pilote amdgpu)
      • Pilote de rendu pour les anciennes générations (pilote radeon)
      • Pilote HSA (pilote amdkfd)
    • Intel (pilote i915)
    • NVIDIA (pilote nouveau)
    • VirtIO (pilote virtio-gpu)
    • Pilotes graphiques pour systèmes monopuces
  • Réseau
    • Suppression du cache pour les routes en IPv6
    • Lecture des en‐têtes du premier paquet TCP (SYN) sur une interface de connexion
    • Un nouvel algorithme de gestion de congestion pour TCP
    • Meilleure allocation des ports TCP/UDP
  • Sécurité
    • LSM
      • IMA
      • SELinux
      • SMACK
    • EVM
    • Cryptographie
      • Jitter RNG
      • Deterministic Random Bit Generator (DRBG)
      • Nouvelle API de chiffrement de clef publique
      • Matériel
    • Divers
    • sysfs, /proc et les conteneurs
    • Liste non exhaustive des vulnérabilités corrigées
  • Systèmes de fichiers
    • • FUSE
      • Btrfs
      • F2FS
      • GFS2
      • ext4
      • NCQ TRIM
    • ext3 est en cours de suppression
  • Virtualisation
    • KVM
    • Xen
• Le bilan en chiffres
• Appel à volontaires

Annonces des RC par Linus Torvalds

RC-1

La version RC-1 est sortie le dimanche 5 juillet 2015 :

C’est dimanche, deux semaines se sont écoulées et la fenêtre d’intégration est fermée. J’ai seulement mis à jour la référence dans les branches git ; les archives tar et les corrections devraient être également disponibles.

Je pensais que cette RC serait l’une des plus grosses que nous ayons eues, mais il se trouve que tout dépend de la manière de compter. Si l’on compte seulement le nombre de modifications, c’est effectivement l’une des plus grosses RC-1 de l’histoire récente, mais la 3.10-rc1 était pratiquement aussi grosse et, à partir de là, elle a grossi vraiment plus que d’habitude. Je doute que nous égalions la taille de la 3.10 au moment de la sortie, étant donné que nous avons fait des progrès pour ne pas intégrer de grosses modifications après la sortie de la RC-1.

Et il se trouve que la 3.15-rc1 avait plus de modifications que la 4.2-rc1 (ça se joue à un cheveu), donc, encore une fois, ce n’est pas la plus grosse RC1 de tous les temps, si l’on compte le nombre de modifications.

Mais ça reste vraiment une des plus grosses. Les changements sont bien trop nombreux pour pouvoir en communiquer la liste, et donc, comme d’habitude pour les RC1, j’ai joint mon journal de fusion, dans lequel les personnes nommées sont celles dont j’ai fusionné les changements, et pas forcément celles qui ont effectivement écrit le code. Pour avoir le détail, jetez un œil dans le dépôt git.

Cependant, si l’on regarde uniquement le nombre de lignes modifiées, c’est vraiment la plus grosse de toutes les RC que nous ayons jamais eue, avec un peu plus d’un million de lignes ajoutées (et presque 250 000 lignes enlevées). Cela dépasse le précédent record (3.11-rc1), dont la taille était principalement due à l’ajout de Lustre dans la branche staging.

Ce nombre important de lignes est largement dû à une seule cause : l’ajout massif des nouveaux en-têtes de descriptions de registres des cartes graphiques d’AMD. En fait, ces en‐têtes de descriptions de registres représentent à eux seuls 41 % de l’ensemble des modifications. Le reste de ce nouveau pilote de périphérique représente encore 8 % du total, ce qui fait que l’on se retrouve dans la situation pour le moins étrange dans laquelle un seul pilote couvre presque la moitié de la RC-1 en nombre de lignes.

À part cette anomalie peu courante, le reste semble plutôt normal — principalement des pilotes et des mises à jour d’architectures. L’architecture Renesas H8/300 est revenue sous une nouvelle forme après nettoyage, ainsi nous prenons en charge de (pseudo) nouvelles architectures, mais c’est petit comparé au volume de modifications provenant d’ARM (avec x86, loin derrière). Il est intéressant de remarquer qu’il y a eu quelques changements dans le code de bas niveau de l’architecture x86 : à la fois une réorganisation du code source du prologue x86, et beaucoup de nettoyage dans la gestion des unités de calcul à virgule flottante. C’est plutôt inhabituel, étant donné que le code de bas niveau x86 est plutôt stable et qu’il est rare d’y voir de gros changements.

Hormis les « pilotes et les architectures », il y a beaucoup de modifications dans les systèmes de fichiers, y compris des changements fondamentaux et du nettoyage dans la gestion des liens symboliques par Al. Ainsi que toutes les mises à jour habituelles dans les différents systèmes de fichiers, le réseau, la cryptographie, les outils, les tests, etc.

Linus

RC-2

La version RC-2 est sortie le dimanche 12 juillet 2015 :

Une autre semaine, une autre RC. Que dire ? Trouvez‐moi ennuyeux, mais c’est comme ça que ça marche.

Ce n’est pas une RC particulièrement grosse, et ça a été plutôt calme. Il y a, certes, eu quelques ennuis avec la RC-1, mais tout ça semblait plutôt négligeable, donc espérons que la RC-2 se terminera avec encore moins de problèmes ennuyeux.

La RC-2 se compose en gros d’un tiers de pilotes (DRM en constitue l’essentiel), un tiers d’architectures (ARM, MIPS et PA-RISC, et un brin d’x86) et un tiers de divers. Ce qui sort du lot concerne principalement les systèmes de fichiers (Btrfs) et quelques mises à jour concernant les minuteurs, et les outils de gestion des performances propres à l’infrastructure de l’outil plutôt qu’au noyau.
Le journal abrégé ci‐dessous donne plus de détails, vous pouvez le parcourir rapidement (il n’est pas si gros) pour avoir une idée de ce qui a été fait.

Allez‐y, testez et vérifiez que tout fonctionne bien.

Linus

RC-3

La version RC-3 est sortie le dimanche 19 juillet 2015 :

C’est un dimanche habituel, avec une sortie de RC relativement normale. Il y a eu quelques retombées dues au nettoyage des routines des unités de calcul en nombres flottants sur x86, mais ça ne concerne que les processeurs avec l’instruction xsaves, et tout devrait être rentré dans l’ordre maintenant.

Il y a approximativement 50 % de pilotes, le reste est constitué pour moitié de « mises à jour d’architectures » (x86, ARM, m68k, S390 et ARC) et le reste est constitué d’un peu de tout. Du réseau, des outils, du système de fichiers, etc.

J’aurais aimé que la RC-3 soit un peu plus petite qu’elle ne l’est, mais je ne pense pas qu’il y ait quoi que ce soit de particulièrement effrayant qui se trame.

Linus

RC-4

La version RC-4 est sortie le dimanche 26 juillet 2015 :

Nouvelle semaine, nouvelle RC.

J’espérais vraiment que l’activité se calme, mais ce n’est pas encore le cas. Il n’y a rien de spécialement gros ou effrayant, mais nous n’avons toujours pas atteint le stade à partir duquel le rythme diminue et que les bogues deviennent vraiment insignifiants.

Nous avons encore eu quelques bogues liés au travail de nettoyage bas niveau de l’assembleur x86 et de l’instruction syscall, concernant la compatibilité 32 bits (uniquement utile pour AMD) qui s’est retrouvée subtilement cassée. Tout devrait être désormais corrigé, donc si vous utilisez un noyau 64 bits avec un espace utilisateur 32 bits (notamment des outils tels que Wine, etc.) et que vous avez rencontré des soucis auparavant, mettez‐vous à jour.

Bien sûr, merci de vous mettre à jour, même si vous n’avez pas eu de problème jusqu’ici, juste pour tester la nouvelle RC.

Si l’on excepte ce problème, il s’agit principalement de pilotes et du réseau. USB, processeurs graphiques, pilote MMC, pilotes réseau, audio. Avec un peu d’activité du côté d’ARM due essentiellement à des pilotes, avec des mises à jour de l’arbre des périphériques correspondant à des corrections, la gestion des cartes mémoire multimédia MMC. Nous avons aussi quelques petites corrections dans les systèmes de fichiers.

Allez‐y, testez.

Linus

RC-5

La version RC-5 est sortie le dimanche 2 août 2015 :

Nous arrivons maintenant dans les dernières RC, mais il semblerait que cette 4.2 soit une version qui nécessitera sans doute plus de RC que les sept habituelles. Les choses ne se calment pas comme je l’avais espéré, et un nombre important de problèmes ont été découverts.

Par exemple, il y a un correctif dans le cœur de VFS qui a été seulement fusionné hier – le bogue en lui‐même était ancien, mais certains changements apportés par cette version l’ont rendu beaucoup plus visible et fréquent. Il y a également des régressions sur le MST DP i915 qui sont relativement cachées, mais qui nécessitent encore du travail, tout comme les quelques manques autour du nettoyage bas niveau du code x86 et des interruptions non masquables (NMI). De plus, il y a également des questions en attente concernant des changements dans la mémoire virtuelle.

Rien de cela n’est particulièrement méchant, et ces bogues sont des cas très spécifiques, difficiles à atteindre, et des points de détails, ce qui fait que je ne suis pas particulièrement inquiet. Mais c’est plus que je ne l’escomptais à ce niveau de version. Peut‐être que dans deux semaines, lorsque la RC-7 sera là, je serai plus serein, les choses iront bien et je serai prêt à valider la sortie d’une 4.2, mais actuellement, j’espère juste que les choses vont se tasser et qu’il n’apparaîtra pas d’autres problèmes.

Mis à part ces petits désagréments, les choses semblent plutôt classiques. Pas beaucoup de perturbations dues aux architectures cette fois‐ci (mis à part ce problème de NMI relaté précédemment) – et un peu plus des trois quarts des modifications sont dues aux pilotes, avec DRM, InfiniBand, réseau, et gestion de charge SCSI. Le reste est composé principalement de modifications de système de fichiers et de code réseau.

Vous pouvez consulter le résumé de la liste des modifications, qui donne une assez bonne vue sur les détails. S’il vous plaît, continuez à tester. Et sachez que si vous m’envoyez une demande d’intégration que je considère comme inappropriée, je ne réagirai sans doute pas de manière mesurée (vous êtes prévenus). Nous avons vraiment besoin de ralentir et retrouver un rythme normal (bien que cette RC-5 ne soit pas vraiment si grosse que ça).

Linus

RC-6

La version RC-6 est sortie le dimanche 9 août 2015 :

La semaine dernière, je n’étais pas satisfait de l’état des RC, mais ça va mieux. Non seulement, la RC-6 est beaucoup plus petite, mais en plus les problèmes qui m’embêtaient ont été résolus au début de la semaine, et il n’en reste pas de graves. Si tout va bien, je pense que nous terminerons selon le calendrier habituel (c’est‐à‐dire dans deux semaines). Touchons du bois.

Dans la RC-6, les statistiques semblent un peu bizarres, parce que les modifications de l’architecture ARC dominent (30 % du total). C’est dû au fait que les autres changements sont plutôt petits, et aussi que la correction du « llock/scond livelock » n’était pas petite. Mais je ne m’inquiète pas.

Si on exclut la bizarrerie ARC, tout paraît normal. Principalement des pilotes (pilotes graphiques, son, I²C, entrée, USB, thermique, etc.) et des mises à jour d’architectures (MIPS et SPARC). Avec quelques corrections des systèmes de fichiers et de la mémoire virtuelle.

S’il vous plaît, testez et vérifiez que les problèmes ont bien été corrigés. OK ?

Linus

RC-7

La version RC-7 est sortie le dimanche 16 août 2015 :

En général, ces temps‐ci, la RC-7 est notre dernière RC, et la semaine prochaine devrait sortir la version 4.2 finale. Mais à ce stade, je n’ai toujours pas pris ma décision. Au moment de la RC-5, je m’inquiétais de quelques questions en suspens. Puis, dimanche dernier, pour la RC-6, j’étais plus confiant. Et maintenant, une semaine plus tard, et nous avons constaté quelques répercussions provenant de la réécriture du prologue x86 bas niveau, et je ne sais plus.

Donc, ça peut être la dernière RC, ou pas. Cela dépendra si d’autres problèmes surviennent la semaine prochaine, et de mon ressenti dimanche prochain. Une partie de moi est convaincue que les problèmes bizarres de compatibilité 32 bits, etc., sont enfin réglés, mais l’autre partie de moi est encore un peu méfiante.

Dans l’ensemble, ça s’est assez bien passé. C’est une bonne petite RC, avec des statistiques relativement normales. 70 % de pilotes (réseau, NTB, Xen, md, pilotes graphiques), le reste étant principalement constitué de quelques mises à jour d’architectures et de réseau, hors pilotes. Le mini‐journal en annexe donne les détails habituels — il est vraiment court.

Par conséquent, une sortie la semaine prochaine est certainement encore possible.

Linus

RC-8

La version RC-8 est sortie le lundi 24 août 2015 :

La version 4.2-rc8 est disponible, et évidemment ça signifie que finalement je me suis dégonflé, et que j’ai décidé de retarder la version finale d’une semaine.

Il n’y a plus vraiment de problèmes non résolus, et donc j’ai hésité entre sortir la version finale ou une autre RC. Mais comme cette semaine nous avons eu un autre problème de bas niveau sur x86, et qu’en plus beaucoup de personnes sont en vacances, j’ai décidé qu’attendre une semaine de plus ne ferait pas de mal. Mais il s’en est fallu de peu. Cette RC-8 est assez petite, et je pense vraiment que ça aurait pu le faire dans les deux cas.

Donc la RC-8 n’est pas une grosse RC et la majorité des changements sont des annulations de modifications de dernière minute qui n’étaient pas vraiment prêtes. Surtout des changements sur les pilotes, le réseau, des correctifs sur x86 et une poignée de correctifs sur l’outillage de performance. La liste de modifications donne une vue d’ensemble détaillée.

Linus

Version finale

La version finale est sortie le 30 août 2015 :

Donc, à en juger par le peu d’activité de cette semaine, ce n’aurait pas été une erreur de sortir la version 4.2 la semaine dernière, après tout. Mais il y a vraiment eu quelques corrections effectuées, et retarder la version 4.2 d’une semaine ne posait pas vraiment de problème.

Donc, la voici, et la fenêtre de fusion pour la version 4.3 est à présent ouverte. J’ai déjà en attente quelques demandes anticipées d’intégrations, mais comme toujours je commencerai à les traiter demain et donnerai à la version 4.2 le temps de s’installer.

La liste des changements par rapport à RC-8 est minuscule et se trouve en annexe. Le correctif est plutôt petit lui aussi.

Allez la récupérer.

Linus

Liste des nouveautés

• 4.2 Merge window part 1
• 4.2 Merge window part 2
• 4.2 Merge window part 3

Architecture

Systèmes monopuces ARM

• Les processeurs Allwinner A23 ainsi que les Broadcom BCM63138 bénéficient de la prise en charge du SMP (multiprocesseur).
• Un embryon de prise en charge pour la carte i.MX7d. L’i.MX7 dispose de deux cœurs Cortex-A7 pouvant atteindre des fréquences de 1,0 GHz, ainsi que d’un cœur Cortex-M4 cadencé jusqu’à 256 MHz, le tout avec une prise en charge des mémoires LPDDR2 et LPDDR3, un bus Ethernet gigabit, et un bus PCI Express. La série des i.MX7 est principalement réservée à ce que l’on appelle communément « l’Internet des objets ».
• Un embryon de prise en charge pour le ZTE ZX296702, qui dispose d’un double cœur Cortex-A9, ainsi qu’une puce Mali 400.
• Une prise en charge pour le NVIDIA Tegra HDA.
• Une prise en charge pour les nouvelles plates‐formes Broadcom suivantes : Buffalo WXR-1900DHP, SmartRG SR400ac, et ASUS RT-AC87U.
• Une prise en charge pour la carte ARM Juno.
• Une prise en charge pour le système monopuce HiSilicon Hi6220, permettant ainsi de faire fonctionner la carte HiKey (carte disposant d’un Cortex-A53 octocœur 64 bits pour 130 US$).
• La plate‐forme mvebu prend désormais en charge le Compulab CM-A510, le D-Link DNS-327L et les cartes Linksys basées sur un Armada 385.
• La plate‐forme OMAP gagne également la prise en charge du Baltos IR 5221, du LogicPD Torpedo, ainsi que du Toby Churchill SL50 (lien vers le SL40, aucun lien vers le SL50 n’existe pour le moment).

Renesas H8/300

Le noyau Linux gagne encore en portabilité en ajoutant la prise en charge d’un nouveau processeur, le Renesas H8-300 dans sa version 32 bits. Ce processeur se retrouve par exemple dans les Lego Mindstorms. Jusqu’alors, sa prise en charge était maintenue dans un arbre séparé du noyau officiel. Il est désormais intégré au noyau 4.2 grâce à un ajout de plus de 7 000 lignes de code.

ARCv2, HS38 CPU Cores

Les processeurs HS38 issus d’une architecture ARCv2, et développés par DesignWare, sont désormais directement gérés dans le noyau. Cette évolution de l’architecture ARC est censée être deux fois plus performante, tout en ayant une faible consommation et un nombre de transistors peu élevé.

Général

Amélioration des verrous

Grâce à une amélioration des verrous (passage de ticket spinlock à qspinlocks), la montée en charge sur les systèmes ayant beaucoup de processeurs et les architectures à mémoire non uniforme (NUMA) va être plus performante. Cela ne dispense cependant pas les développeurs de travailler leurs verrous [Cf. phoronix.com].

Amélioration de l’ordonnanceur

Diverses améliorations de l’ordonnanceur, dont l’équilibrage sur les systèmes NUMA [Cf. phoronix.com].
Amélioration de performance des disques à mémoire Flash SSD de 12 % sur certains tests, quatre fois sur d’autres tests en désactivant des choses inutiles sur les disques statiques, comme la NCQ, et autres mesures qui laissaient des temps à vide pour le SSD.
[Cf. phoronix.com].

Le nettoyage du code d’assemblage continue

La suppression du code d’assemblage x86 commencée dans le noyau 4.1 continue. De petites améliorations de vitesse et des micro‐optimisations sont à attendre. Cela améliore aussi la gestion des interruptions [Cf. phoronix.com].

Plus de limite pour une suite de liens symboliques

Le code principal de recherche des noms de fichiers a été retravaillé afin de ne plus utiliser la récursivité. Les effets seront visibles au niveau de l’utilisation de la pile, qui sera réduite (améliorant la fiabilité des systèmes de stockage complexes) et de la limite des niveaux d’imbrication des liens symboliques, qui a été relevée.

L’appel système splice et les sockets Unix

Les sockets de domaine Unix gèrent désormais l’appel système splice().

Control group write back

Les correctifs d’écriture différée selon le groupe de contrôle (cgroup) ont été intégrés. Cela permet un meilleur contrôle de l’écriture de données selon les groupes de contrôle, corrigeant des comportements qui étaient depuis longtemps défaillants [LWN.net].

Développeurs

Amélioration de l’outil perf

Comme à chaque nouvelle version, l’outil perf bénéficie de son lot d’améliorations listées dans le correctif suivant.

Pilotes graphiques libres

Direct Rendering Manager

Maintenant au sein de DRM, l’interface logicielle (API) de gestion atomique du mode graphique est considérée comme complète, elle est donc exposée par défaut à l’espace utilisateur. Cette interface, intégrée initialement dans Linux 4.0, permet à l’espace utilisateur de vérifier si une configuration est gérée par le matériel avant de l’appliquer. Cela devrait donc permettre d’exploiter l’interface logicielle KMS des plans graphiques ajoutée dans Linux 3.19. Martin Graßlin, développeur du compositeur KWin, a déjà exprimé son souhait d’utiliser cette nouvelle interface, afin de réduire à néant les coûts liés à la composition graphique. Pour plus d’informations sur le sujet, vous pouvez consulter les articles écrits par Daniel Vetter, mainteneur du pilote i915 (Intel), sur LWN.net [partie 1 et partie 2].

Pour plus d’informations, vous pouvez consulter les demandes d’intégration DRM et panneaux.

AMD/ATI

Pilote de rendu nouvelle génération (pilote amdgpu)

Plus d’un an et demi après son annonce à la Game Developer Conference 2014, le pilote AMDGPU est enfin fusionné dans le noyau. Ce pilote, issu d’AMD, représente le nouveau cœur dans le noyau pour la gestion des cartes à base de processeur graphique AMD CI+. Le but pour AMD est d’avoir une interface unifiée, tant pour les pilotes libres que pour les pilotes propriétaires. Cette nouvelle architecture permet de garder les pilotes (que ce soit Gallium3D ou Catalyst) en espace utilisateur. Ce pilote a nécessité l’ajout de plus de 400 000 lignes de code, et de plus de 200 fichiers.

Cette fusion des équipes de développement noyau devrait garantir la gestion des futures générations de processeurs graphiques AMD avant leur sortie commerciale, mais également augmenter la stabilité et les performances des deux pilotes.

La FSF s’est permis de rappeler que cette architecture n’est cependant pas plus ouverte que la précédente. En effet, le pilote AMDGPU intègre un paquet binaire redistribuable à charger sur les cartes AMD pour pouvoir être fonctionnel, comme sur le pilote RADEON.

Pour plus d’informations, vous pouvez regarder la conférence d’Alex Deucher à l’XDC 2014, la conférence des développeurs X.Org qui s’est déroulée à Bordeaux en octobre dernier. Vous pouvez également consulter la demande d’intégration.

Pilote de rendu pour les anciennes générations (pilote radeon)

Avec l’introduction du pilote AMDGPU, la majorité des efforts de développement devrait maintenant se concentrer sur ce pilote. Le pilote radeon continuera à être maintenu et amélioré, mais à un rythme bien plus lent.

Cette nouvelle version du pilote apporte cependant une fonctionnalité importante, la gestion du codage vidéo avec le moteur matériel VCE1. Ce moteur a été ajouté fin 2011 aux processeurs graphiques AMD et permet de compresser directement des vidéos au format H.264 / MPEG-4 AVC. Cette fonctionnalité est destinée à permettre l’enregistrement de la sortie vidéo et la diffusion en temps réel de cette vidéo depuis un ordinateur puissant vers une machine plus économe située directement dans le salon de joueurs (voir la solution GameStream de NVIDIA). Elle permet également de diffuser ses exploits en direct sur Internet avec une perte de performance plus faible que les solutions traditionnelles de codage sur le processeur (voir Steam Broadcast).

Pour plus d’informations sur les nouveautés du pilote radeon, vous pouvez consulter la demande d’intégration radeon.

Pilote HSA (pilote amdkfd)

Le pilote amdkfd (inclus dans Linux 3.19), qui permet de faire communiquer plus rapidement le processeur graphique et le processeur central, a reçu l’ajout d’un module de gestion d’interruptions et autres événements. Ce module permettra l’ajout d’un nouveau module dédié au débogage des applications HSA.

Un paramètre noyau a également été ajouté afin de spécifier si une application doit recevoir le signal SIGBUS lorsque le processeur graphique rencontre une exception liée à la mémoire et que l’application n’est pas en mesure de recevoir cette information, ou si un message doit être écrit dans le journal du noyau. Ce paramètre est activé par défaut.

Pour plus d’informations, vous pouvez consulter la demande d’intégration amdkfd.

Intel (pilote i915)

Comme d’habitude, le pilote i915 a reçu beaucoup de modifications de la part des ingénieurs d’Intel. Les nouveautés principales sont la finalisation de la gestion dynamique des espaces d’adressage (voir la dépêche sur Linux 4.1), ainsi que l’activation du vérificateur de commandes pour les processeurs Haswell. Ces modifications vont permettre d’activer des extensions OpenGL quand Mesa3D les gérera.

Du côté consommation d’énergie, le pilote a reçu des optimisations afin de réduire l’activité du processeur lors de la vérification des commandes envoyées par l’espace utilisateur. Le pilote a également affiné la configuration du processeur graphique en mode boost afin d’éviter son utilisation lorsque ce n’est pas nécessaire. La gestion des modes basse consommation pour le contrôleur d’affichage fait également son arrivée.

Toujours du côté de la gestion du mode graphique, la gestion atomique ne fait toujours pas partie de Linux 4.2. Mais le travail continue ! On peut cependant noter une gestion expérimentale des processeurs Broxton qui réutilise le bloc d’affichage des processeurs Skylake.

Les processeurs Skylakes et Broxtons sont toujours marqués comme expérimentaux et ne sont pas gérés par défaut. C’est ennuyeux car les processeurs Skylake sont maintenant disponibles à la vente. Espérons que Linux 4.3 éliminera cette limitation.

Toutes les nouveautés ne sont pas décrites ici. Pour plus d’informations, vous pouvez consulter la publication sur le blog de Daniel Vetter, mainteneur i915.

NVIDIA (pilote nouveau)

Aucune nouveauté pour le pilote nouveau. Ben Skeggs, le mainteneur, a été très occupé à réorganiser le cœur du pilote pour que celui‐ci soit plus facile à utiliser et que le compilateur vérifie plus de choses à la compilation. Ce travail vient d’être accepté dans Linux 4.3 et nous partagerons plus d’informations à sa sortie !

Il est cependant à noter que les microcodes nécessaires au processeur graphique du Tegra K1 (GK20A) ont fait leur entrée dans linux-firmware.

VirtIO (pilote virtio-gpu)

Le pilote graphique pour systèmes virtualisés gérant VirtIO fait son entrée dans le noyau. Celui‐ci exporte pour l’instant uniquement l’interface KMS, sans accélération graphique 3D. Cette interface est utilisable directement avec un compositeur Wayland ou via l’utilisation du pilote xf86-video-modesetting. Le pilote virtio-gpu a cependant pour vocation de proposer une accélération 3D via Virgil3D.

Pour plus d’informations, vous pouvez consulter la demande d’intégration virtio-gpu.

Pilotes graphiques pour systèmes monopuces

Le pilote Omapdrm a été partiellement réécrit pour corriger des bogues (crash au déchargement des modules, cisaillements lors des changements de pages, etc.) présents depuis des années. Il en résulte un code plus lisible et maintenable, tout en étant plus stable et robuste. Le code a été majoritairement testé sur la Pandaboard OMAP4, avec un et deux écrans.

Le pilote DRM/MSM (pour les puces graphiques SnapDragon) voit l’ajout de la prise en charge de l’Adreno 306 que l’on retrouve dans le SnapDragon 400c. Ce dernier promet d’être moins énergivore que son prédécesseur, l’Adreno 305.
De plus, nous avons droit aux habituels correctifs (assez nombreux), et l’ajout de la prise en charge du format de tampon NV12MT.

Réseau

Suppression du cache pour les routes en IPv6

Si vous avez bonne mémoire, vous vous souvenez peut‐être de la suppression du cache des routes en IPv4, décrite dans la dépêche sur le noyau Linux 3.6.

C’est désormais au tour du système IPv6 de recevoir les mêmes changements, grâce à Martin KaFai Lau, développeur employé par Facebook. Son travail s’appuie sur la même idée et permet aux deux versions d’IP de converger à ce sujet dans le noyau Linux.

Ses modifications sont réparties en plusieurs séries, mais la plus importante est celle‐ci. Elle contient notamment des indicateurs de performance, et des détails sur la nouvelle implémentation (qui continue de sauvegarder les routes avec des MTU différentes).

Lecture des en‐têtes du premier paquet TCP (SYN) sur une interface de connexion

Lorsqu’un développeur d’applications ouvre une interface de connexion (socket) avec le protocole TCP, il ne peut habituellement obtenir des informations sur la connexion qu’une fois que la poignée de main (SYN-ACK, ACK) est terminée.

Les informations contenues dans les en‐têtes du premier paquet reçu sont perdues, l’application ne peut pas y avoir accès.

Google semble avoir un cas d’utilisation d’étude de ces paquets, à des fins d’empreintes numériques. Les développeurs de Google ont donc proposé une modification ajoutant une option pour faire sauvegarder les en‐têtes de ce paquet par le noyau, et pour demander à les lire ensuite.

Pour la petite histoire, les développeurs de chez Google indiquent utiliser depuis trois ans une approche équivalente en interne.

Un nouvel algorithme de gestion de congestion pour TCP

La gestion de congestion de TCP est essentielle à tout réseau : c’est elle qui permet d’éviter de prendre toute la bande passante disponible avec une seule connexion. Son principe est d’augmenter progressivement la vitesse d’une connexion, et de détecter quand le réseau commence à être saturé. C’est à chaque client de vérifier l’état de congestion pour permettre un partage sain des capacités du réseau entre tous les utilisateurs, sans aucun mécanisme central.

Même en considérant que tous les clients vont coopérer correctement, ce problème est très loin d’être trivial, notamment pour une détection de saturation réseau correcte. La plupart des algorithmes se basent sur la détection de perte de paquets. Pour qu’un paquet soit considéré comme perdu, il faut d’abord être certain qu’il n’a pas été reçu (donc utiliser un délai de grâce, ce qui augmente la latence). Cette détection peut être compliquée par le fameux problème de saturation de tampon (buffer bloat). Enfin, un réseau peut connaître de la perte naturelle de paquets, sans pour autant être congestionné.

Le nouvel algorithme introduit dans le noyau s’appelle Delay-gradient congestion control. Comme son nom l’indique, l’idée est de changer d’approche. Plutôt que de construire la détection de congestion sur la perte de paquets, mécanisme peu fiable, cet algorithme se base sur les variations du délai de transmission (RTT). Quand ce délai augmente de façon anormale, une congestion est détectée et l’émission de paquet est adaptée pour en tenir compte. Pour plus de détails, le site LWN.net a détaillé le mécanisme.

Pour rappel, vous pouvez consulter les algorithmes disponibles sur votre noyau préféré avec /proc/sys/net/ipv4/tcp_available_congestion_control, et vérifier ou configurer l’algorithme utilisé avec /proc/sys/net/ipv4/tcp_congestion_control.

Meilleure allocation des ports TCP/UDP

Les ports TCP et UDP sont essentiels pour identifier de façon unique une connexion réseau entre deux équipements. Ces ports ne sont pas très nombreux, il ne peut y en avoir que 65 535 pour ces protocoles.

Cela pose un problème pour des serveurs très chargés avec énormément de connexions à ouvrir. Soit il n’y a plus de ports disponibles (et la connexion échoue), soit on peut passer un temps très important à trouver un port disponible, prenant des ressources à tout le monde.

Il y a cependant deux types de ports : ceux qui sont utilisés par un socket serveur ne peuvent être utilisés par quiconque d’autre. On n’a pas le contrôle sur les identifiants utilisés par les clients, on ne peut donc pas prendre le risque côté serveur de réutiliser ce port.

En revanche, pour les sockets client, on peut très facilement réutiliser les ports en maintenant l’unicité de l’identification réseau (basée sur les deux adresses IP, les deux ports, et le protocole utilisé) :

Adresse locale	Adresse distante	Port source	Port destination
A	B	2000	80
A	C	2000	80
A	B	2001	80

La solution proposée par Éric Dumazet est donc de séparer cet espace de ports en deux parties : une pour les utilisateurs de la fonction connect() (client), une autre pour les utilisateurs de la fonction bind() (serveur). En divisant ainsi l’espace, on fait gagner du temps à tout le monde (il est très probable que la fonction connect() pourra partager un port dans les premiers trouvés, tandis que la fonction bind() aura beaucoup moins de vérifications à faire). Si par hasard un des espaces était totalement utilisé, l’itération se poursuivrait sur le second [correctif].

Sécurité

LSM

Les modules de sécurité Linux (LSM) peuvent être « empilés » pour effectuer plus de contrôles de sécurité. Il n’est pour l’instant pas possible d’utiliser simultanément plusieurs modules « monolithiques » : les structures opaques de sécurité présentes un peu partout dans le noyau n’ont pas été dupliquées. Cela signifie donc qu’il est possible d’empiler plusieurs modules « simples » (pour l’instant il n’existe que Yama) avec d’autres modules « lourds » (SELinux, SMACK…).

Par la même occasion, les vérifications liées aux « capabilities » ont été regroupées dans un nouveau module générique qui est empilé par défaut avant tous les autres. Le code pour effectuer ces vérifications a été retiré de tous les autres modules, ce qui lève certaines ambiguïtés et évite la duplication du code.

(Correctifs : 1, 2, 3, 4, 5, 6, 7 ; article LWN.net : Progress in security module stacking).

IMA

Les fichiers des systèmes de fichiers virtuels pour les cgroups et les espaces de noms ne sont plus vérifiés par défaut. Les autres systèmes de fichiers virtuels (devpts, SELinux, binfmt…) sont aussi suggérés comme « à ignorer » dans la politique de test par défaut, parce que les opérations effectuées par IMA ne sont pas pertinentes dans ce cas [correctifs : 1 et 2].

Avec IMA, les signatures des fichiers sont automatiquement définies et mises à jour et ne doivent pas être modifiées à la main par un utilisateur. Dans certains cas, cette opération peut tout de même être nécessaire. Elle est donc limitée aux modes fix et log [correctif].

La nouvelle condition euid ajoutée pour les politiques de sécurité permet de vérifier l’intégrité des fichiers accédés par un processus avec un euid défini. Pour les fichiers CAP_SETUID, les uid et les suid sont pris en compte [correctif].

La règle de filtre mask est étendue pour filtrer les ouvertures de fichiers contenant un ou plusieurs modes MAY_READ, MAY_WRITE ou MAY_APPEND au lieu d’un seul uniquement. Par exemple, mask=^MAY_READ correspondra à l’ouverture de fichiers en lecture et écriture [correctif].

Une nouvelle politique nommée tcb est incluse par défaut. Elle est similaire à la politique ima_tcb existante mais ajoute des règles tirant parti des améliorations mentionnées ci‐dessus. Le changement de la politique ima_tcb aurait potentiellement cassé le fonctionnement des systèmes actuels. Donc, au lieu de définir une nouvelle politique à chaque changement des options par défaut, une nouvelle option de démarrage est définie (ima_policy=) pour spécifier quelle politique incluse utiliser. La politique ima_tcb n’est plus prise en charge [correctif].

SELinux

La liste des classes de sockets netlink a été mise à jour pour tenir compte des nouveaux ajouts dans le noyau. Les classes désormais inutiles ont aussi été supprimées [correctif].

Les fichiers des systèmes de fichiers virtuels sysfs, pstore et debugfs peuvent être étiquetés chacun avec un contexte différent. L’utilisation de ces fichiers peut donc faire partie des contrôles d’une politique de sécurité. Cette amélioration est importante dans le cas d’Android, où certains fichiers de debugfs ont besoin d’être lus par des applications et le système doit donc être accessible par tous, ce qui induit un risque en termes de sécurité [correctifs : 1 et 2].

Un nettoyage de certaines définitions de permissions d’accès obsolètes a été réalisé [correctif].

Une correction a été effectuée pour un bogue introduit par un précédent correctif, qui n’avait pas tenu compte du cas où un système de fichiers était en fait un montage NFS v4.2 [correctif].

Le stockage des catégories NetLabel est maintenant plus optimal, et cela corrige indirectement un bogue sur les systèmes 32 bits [correctif].

Un correctif ajouté dans le noyau 4.1 a introduit une régression qui entraînait la non exécution des vérifications de sécurité pour les accès aux zones de mémoire partagées anonymes. Un nouveau correctif rétablit la situation.

SMACK

Le partage de descripteurs de fichiers DMA-Buf ne fonctionnait pas car SMACK n’était pas capable de récupérer leurs attributs étendus. Cette situation est pour l’instant ignorée, ce qui autorise le partage de ces descripteurs de fichiers [correctif].

Dans certains cas, les erreurs n’étaient pas remontées jusqu’à l’espace utilisateur, ce qui ne permettait pas de savoir d’où venait le problème. Cette situation est prise en charge par ce correctif.

SMACK peut limiter l’usage des capacités CAP_MACADMIN et CAP_MAC_OVERRIDE aux processus s’exécutant avec une étiquette spécifique. Mais n’avoir qu’une seule étiquette n’est pas suffisant dans certains cas (Tizen). L’interface onlycap peut désormais accepter plusieurs étiquettes [correctif].

EVM

Pour éviter que les attributs étendus utilisés par EVM soient supprimés lorsque le système est éteint et régénérés automatiquement à l’exécution, EVM autorise uniquement les fichiers à recevoir une étiquette au moment de leur création. Mais comme les systèmes de fichiers virtuels ne sont pas persistants, la suppression de leurs attributs n’est pas un souci. Cette fonctionnalité est utilisée par certains modules LSM (SELinux ou SMACK, par exemple) [correctif].

Cryptographie

Cette nouvelle version du noyau prend en charge les Chacha20, Poly1305 et RFC7539 [correctifs : 1, 2, 3, 4, 5, 6, 7 et 8].

L’implémentation de SHA-512 a été remplacée par celle, plus flexible, utilisée par le projet OpenSSL. Cette dernière contient une version accélérée pour ARM64 et une version générique [correctif].

Jitter RNG

Une nouvelle source d’entropie pouvant être utilisée uniquement à l’intérieur du noyau a été introduite. Elle n’est donc pas exposée à l’espace utilisateur. Le « jitterentropy RNG » mesure certains intervalles de temps entre des accès mémoire et des instructions exécutées par le processeur pour générer une suite de bits qui vérifie certaines propriétés de non déterminisme. Cela ne permet pas de prouver que l’ensemble est réellement aléatoire, donc il va principalement être utilisé comme graine supplémentaire et non comme remplacement des autres sources d’entropie [correctif ; article LWN.net : Random numbers from CPU execution time jitter ; CPU Jitter Random Number Generator].

Deterministic Random Bit Generator (DRBG)

Le DRBG remplace le générateur de nombres aléatoires par défaut dans le noyau. Il est alimenté par le « jitterentropy RNG » comme source additionnelle [correctifs : 1, 2, 3, 4, 5, 6, 7, 8, 9 et 10 ; SP800-90A Deterministic Random Bit Generator (DRBG)].

Nouvelle API de chiffrement de clef publique

Cette nouvelle interface logicielle permet l’implémentation de calcul déporté de manière asynchrone, lorsque le matériel requis est présent et pris en charge par l’API de chiffrement de Linux [correctif].

Matériel

La gestion du module d’opérations cryptographiques présent sur certaines cartes embarquées Marvell a été ajoutée [correctifs : 1, 2, 3, 4, 5, 6, 7…].

Divers

Tous les usages de structures kernel_param_ops utilisent désormais l’attribut const [correctif].

sysfs, /proc et les conteneurs

Le montage des arborescences sysfs et /proc a été modifié pour n’autoriser que certains dossier particuliers (notamment /sys/debug) à servir de point de montage pour d’autres systèmes de fichiers virtuels. Une nouvelle règle a été ajoutée pour s’assurer qu’une nouvelle instance de ces points de montage (par exemple dans un conteneur) utilise au minimum les attributs de montage utilisés par les instances existantes (nodev, ro et atime). Il avait été proposé d’obliger ces points de montage à être montés avec les options noexec et nosuid, mais cela a été retiré [correctifs : 1, 2, 3, 4, 5, 6, 7, 8 et 9 ; article LWN.net : Enforcing mount options for sysfs and proc].

Liste non exhaustive des vulnérabilités corrigées

• CVE-2015-1333 NVD, Mitre : correctif ;
• CVE-2015-3291 NVD, Mitre : correctif ;
• CVE-2015-5157 NVD, Mitre : correctifs 1 et 2, discussion sur oss-security, explication complète ;
• CVE-2015-3290 NVD, Mitre : correctif ;
• CVE-2015-5697 NVD, Mitre : correctif ;
• ? : correctif.

Systèmes de fichiers

FUSE

FUSE est une interface noyau qui permet d’implémenter des systèmes de fichiers en espace utilisateur. Malheureusement, son manque de performance est pointé régulièrement.
Linus Torvalds a également fait remarquer que FUSE est un jouet destiné aux gens égarés. Malgré cela, de nombreux systèmes ont vu le jour, tels que SSHFS, WebDrive, boxfs, GlusterFS, jusqu’à ZFS. FUSE a été porté sur divers systèmes, tels qu’OS X, FreeBSD ou encore NetBSD.
La montée en charge a été améliorée. Miklos Szeredi a expliqué que l’un des problèmes vient d’une connexion monolithique à FUSE. Le fait de cloner les connexions FUSE permet de ne plus avoir de lecture‐écriture requête‐réponse sur un seul descripteur de fichier et permet au démon FUSE d’avoir de multiples descripteurs, chacun pouvant être utilisé pour recevoir des requêtes et envoyer des réponses [article sur Phoronix.com].

Btrfs

La gestion des quotas sur les sous‐volumes a été mise à jour. La gestion des périphériques a été améliorée, et divers changements ont eu lieu, pour un total de 1 500 lignes de code changées [article sur Phoronix.com].

F2FS

F2FS, le système de fichiers pour NAND et mémoire flash, gère désormais le chiffrement par fichier.
Une amélioration de la gestion du TRIM a été apportée, ainsi que la récupération des superblocs endommagés et diverses corrections [article sur Phoronix.com].

GFS2

Global File System 2 (GFS2) est un système réseau distribué. Des améliorations de performance ont été faites, par exemple sur le renommage des fichiers. La consommation mémoire via les tampons a été réduite. Une meilleure gestion des verrous a abouti à un gain en performances [article sur Phoronix.com].

ext4

La stabilisation et le nettoyage d’ext4 se poursuivent, surtout suite à l’ajout de la gestion du chiffrement. Il est possible de remplir une partie d’un fichier avec des zéros grâce à l’option FALLOC_FL_INSERT_RANGE [article sur Phoronix.com].

NCQ TRIM

Dans la lancée des optimisations SSD faites par l’ordonnanceur, la prise en charge du NCQ TRIM a été améliorée. Il est maintenant activable ou désactivable au démarrage, mais dans beaucoup de micrologiciels le TRIM n’a pas été testé et peut provoquer erreurs et corruptions [article sur Phoronix.com].

ext3 est en cours de suppression

Assuming no major objections come up, the ext3 file-system driver will be dropped for the Linux 4.3 kernel, confirmation de la suppression d’ext3 au profit d’ext4 qui le gère, sur la LKML.

ext4 est rétro‐compatible avec ext3 et ext2, donc cette suppression est sans conséquences. C’est le mainteneur d’ext3 qui a poussé les correctifs. Le mainteneur d’ext4 a déjà donné son accord.

Virtualisation

KVM

• ARM : beaucoup de changements sont en cours, mais rien n’est encore prêt pour cette version, il y a juste des corrections de bogues et l’activation du VFIO qui permet d’avoir un pilote en espace utilisateur pour l’accès direct au matériel d’entrées‐sorties. Un point intéressant pour les performances des machines virtuelles.
• s390 (ordinateurs centraux IBM) : des corrections de bogues et la prise en charge des pages mémoire de plus de 2 Gio.
• x86 : l’hôte et l’invité peuvent utiliser kvmclock en tant qu’ordonnanceur ; prise en charge de l’écriture combinée ; prise en charge du system management mode (SMM), nécessaire au secure boot pour les invités ; implémentation des compteurs de performance virtualisés pour les processeurs AMD. L’allocation PCI legacy est obsolète et l’option de compilation est maintenant de ne pas inclure le mécanisme par défaut à la compilation (remplacé par VFIO). En plus de cela, il y a aussi le chargement opportuniste de contexte FPU pour les invités utilisant beaucoup le calcul à virgule flottante.
• code commun : prise en charge de plusieurs espaces d’adressage. Pour l’instant, seul le code x86 SMM en profite, mais l’équipe derrière le s390 veut aussi l’utiliser.

Xen

• Ajout de make xenconfig pour faciliter la création de noyaux pour invités Xen.
• Préparation de l’intégration des pages mémoire de 64 Kio pour ARM.
• Utilisation automatique de hvc0 pour ARM.

Le bilan en chiffres

Linux 4.2 permet au noyau de passer le cap des 20 millions de lignes de code et plus de 50 000 fichiers. Cette version est la seconde en termes de nombre de modifications depuis l’introduction de Git. En effet, le noyau 3.15 reste malgré tout légèrement plus imposant, mais nous sommes ici en présence d’une grosse version. Outre le nombre de modifications, le nombre de lignes insérées dépasse le million (avec une moyenne de 700 000 depuis l’introduction de Git), alors que le nombre de lignes supprimées reste stable par rapport aux versions précédentes, soit environ 280 000 lignes (avec une moyenne de 300 000 depuis l’introduction de Git).

Cette fois, il faut remonter au noyau 2.6.28 pour espérer avoir une aussi grande variation du nombre de lignes de code. Ce dernier oscille généralement entre 200 000 et 300 000, alors que nous sommes ici à presque 800 000 lignes (moyenne de 230 000).

Bref, une nouvelle version riche de code, et un doublement du nombre de lignes depuis le 25 décembre 2008, où, pour la première fois, le noyau dépassa les 10 millions de lignes de code.

Si vous êtes intéressé par les chiffres bruts, mais bien mis en forme, Thorsten Leemhuis les a compilés dans un beau classeur à découvrir.

Appel à volontaires

Cette dépêche a nécessité plus de 780 éditions (à l’heure de l’écriture de ces statistiques), et mobilisé 22 personnes du 21 juillet au 16 septembre 2015 dans l’espace de rédaction.

Cette dépêche est rédigée par plusieurs contributeurs, dont voici la répartition :

	Mainteneur	Contributeur(s)
La phase de test	Aucun	Robin
Architecture	Romain Perier
Développeurs	Aucun
Pilotes graphiques libres	Martin Peres
Réseau	Aucun	Florent Fourcot
Systèmes de fichiers	Aucun	BRULE Herman
Sécurité	Timothée Ravier
Virtualisation	Xavier Claude
Édition générale	Aucun	eggman, jcr83, M5oul

Un peu de vocabulaire :

• le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
• un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.

Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.

Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.

Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !
C’est un travail à faire au fil du temps, par ajouts successifs (une simple adresse URL ou un § enrichissent déjà le contenu et les sources), n’hésitez-pas !

Aller plus loin

• Dépêches des noyaux précédents (425 clics)
• Site officiel du noyau Linux (378 clics)