Sommaire
En bref
Pourquoi Linux 5.0 ? Rien à dire de particulier, rien de remarquable, c’est juste un changement de version.
Annonces des versions candidates par Linus Torvalds
RC-1
Annonce de la première candidate, le 6 janvier. Note à propos des vacances de fin d’année, et du calme apparent. La quantité de modifications est jugée normale.
Linus annonce à cette occasion que la 4.21 deviendra la 5.0, et en donne l’explication : il n’y a pas de raison particulière, alors faisons‐nous à l’idée, ou notre propre raison.
RC-2
Annonce de la seconde candidate, tout est normal : la fenêtre de fusion est respectée, sauf pour quelques cas pas plus nombreux qu’à l’habitude, le nombre des changements, leur répartition et la quantité de code sont eux aussi dans les standards habituels. Quelques améliorations du côté des outils de suivi des performances sont notées tout particulièrement.
RC-3
Annonce de la troisième candidate. Ici on y trouve une attention particulière sur la pile réseau elle‐même, ainsi que sur les pilotes réseau. Quelques changements côté architectures, surtout MIPS et PowerPC.
RC-4
La quatrième candidate a un cycle un peu excité. Linus signale que plus de demandes d’intégration sont survenues au dernier moment, et que certaines ont été refusées, mais rien d’anormal.
RC-5
Le calme revient pour le cycle de cette cinquième candidate. Un tiers des changements a lieu dans les pilotes. Et Linus parle encore de vacances.
RC-6
Pour la sixième, c’est toujours les pilotes réseau qui sortent du lot. C’est sur des rails que cette sortie se fait, une belle candidate de prime abord.
RC-7
La septième montre des statistiques avec presque la moitié des changements pour les pilotes. Et beaucoup de changements atomiques, petites modifications : on est vraiment dans la correction de bogues et les petites améliorations.
RC-8
Surprise, la RC-7 ne suffira pas, un grand nombre de changements arrive d’un coup. Ce ne sera donc pas une version finale, elle sera estampillée RC-8, repoussant ainsi d’un cycle la sortie de cette 5.0. Cette candidate n’est pas énorme mais propose plus de changements que la précédente. Une semaine de calme sera bienvenue avant la sortie officielle.
Les nouveautés
Des problèmes de performances ?
Michael Larabel a constaté de sévères régressions de performances avec ce noyau 5.0, à tous les niveaux. Tellement qu’on peut légitimement se demander s’il ne se serait pas tout simplement trompé dans les options de compilation ? Notons que ces tests de performance ont été faits avant la sortie du noyau, avant même les dernières RC.
Architectures
x86 & x86-64, Intel et AMD
Ajout de la prise en charge des extensions QoS « Qualité de Service de la plate‐forme » permettant d’avoir une surveillance de l’usage des consommations de certaines ressources, de les allouer et les limiter séparément, pour la nouvelle génération des processeurs AMD, dite « EPYC ». Cette possibilité n’est pas seulement ajoutée, elle est mise en coexistence avec le gestion du RDT pour les processeurs Intel. L’entrée RESCTL est une nouvelle structure accueillant à la fois et INTEL RDT et AMD QoS. La gestion du cache est également mise à jour pour suivre cette évolution.
Toujours du travail pour éliminer empêcher au mieux les failles de la famille « Spectre v2 », par exemple pour les multiples processeurs AMD ayant chacun des spécificités avec leur STIBP (Single Thread Indirect Branch Predictor)
Enfin, de nombreux ajouts pour les ordinateurs portables, des raffinements tels que les touches d’accès rapide pour WMI chez Huawei ou encore le contrôle visuel par DEL (LED) lors de la désactivation du micro pour les portables DELL, et l’équivalent pour les Lenovo.
ARM
Beaucoup de nouveaux systèmes mono-puces (SoC — System on Chips) sont intégrés (NXP/Freescale i.MX7ULP, i.MX8 64 bits avec Cortex A3 et prise en charge de la vidéo 4K, Qualcomm QCS404, Allwinner R40/T3, etc.), ainsi que seize nouvelles plates‐formes (nouveau Linksys EA600 par exemple, i.MX mtrion et i.MX 7D, Rockchip BQ edition, etc.).
La grande famille ARM est également touchée par « Spectre v2 » et a donc aussi son lot régulier de correctifs pour cela. Cette version 5.0 intègre les instructions dites « SB » (speculation barrier) pour la génération ARM v8.5. Voir le commit initial.
Intégration des algorithmes de chiffrement XChaCha12 et XChaCha20 pour tous, ainsi que la gestion de l’accélération matérielle via NEON pour NHPoly1305.
ARM64 bénéfice aussi de la plupart de ces avancées, auxquelles il faut ajouter, entre autres, la gestion de KASLR et la vérification de signatures.
Enfin, l’architecture particulière « big.LITTLE » reçoit une amélioration pour la consommation d’énergie dans l’ordonnanceur de tâches. Les tâches réveillées le sont toujours en priorité sur les cœurs de processeur les moins gourmands en énergie dans cette architecture dissymétrique. Son inclusion dans le noyau commence avec ce correctif et est maintenant complète. Une architecture « big.LITTLE » sur ARMv8 propose jusqu’à quatre cœurs de processeur LITTLE en Cortex A-53 (!) et jusqu’à seize cœurs de processeur Cortex A-57, liés en différentes configurations : autant dire que « ça envoie du bois ».
PowerPC
Belle avancée pour le PowerPC, avec l’ajout de la gestion des Huge Pages de 8 Mio (et celles de 512 Kio). Pour rappel, le processeur alloue par défaut de la mémoire vive par page de 4 Kio. Plus il y en a et plus de temps processeur est pris pour trouver la bonne page à la demande. Les Huge Pages proposent donc des « chunks » plus gros et des pages plus larges. Les applications qui en bénéficient sont surtout les bases de données, la virtualisation, et l’usage de différents procédés de cache mémoire (memcached par exemple).
Un PowerPC a également du travail pour combattre « Spectre v2 » : le processeur NXP Book3E de chez Freescale.
Autres
Ajout d’une prise en charge préliminaire pour Loongson 3A R2.1 et amélioration du côté de ptrace pour les MIPS. Du côté de RISC-V, la gestion pour l’audit est là.
Gestion de la mémoire
Parmi les changements et améliorations dans la gestion de la mémoire vive :
Réorganisation du tableau de l’OOM Killer
L’OOM Killer (out of memory management) est un mécanisme s’enclenchant lorsqu’il n’y a plus aucune mémoire disponible : le noyau construit un tableau de victimes potentielles pour tuer celles présentant à la fois une forte consommation de ressources et ayant une fonction non essentielle. Le noyau préserve ainsi le système et les services rendus. Cas d’exemple : une fuite mémoire dans un script Python utilisant gdal, au lieu de faire un écran bleu, ce script sera tué et le système continuera d’être opérationnel pour les autres — mais cette réorganisation ne changera pas l’OOM killer en l’adaptant pour les machines de bureau : il continuera de tuer joyeusement et avec bonne humeur votre LibreOffice.
Réduction de la fragmentation des Transparent Huges Pages
Du côté des Transparent Huges Pages (THP), la fragmentation a été réduite de 90 %, améliorant probablement leurs performances. Il ne s’agit pas d’une nouveauté à proprement parler mais de la suite d’un travail constant. Si discuter des évitements de fragmentations de la mémoire vive dans un contexte d’usage des THP ne vous fait pas mal au crâne, ce commit explique en détails les enjeux et les améliorations apportées dans cette version.
Retours d’information des défaillances mémoire
Des améliorations sur les retours d’information en cas de défaillance d’une mémoire, permettant de mieux identifier le problème, voir ce commit.
Option de désactivation de kmemleak lors de l’amorçage
Une nouvelle option permettant de désactiver le kmemleak à l’amorçage du système a été ajoutée. Pour mémoire, kmemleak propose une façon pour identifier les fuites mémoire des applications en espace utilisateur (d’autres méthodes existent, avec Valgrind par exemple). Ce procédé scanne la mémoire vive périodiquement. Offrir sa désactivation permet d’alléger le processeur pour des environnements et systèmes où le débogage n’est pas ciblé ou utilisé.
Sécurité
Nouvelles commandes TPM2
De nouvelles commandes spécifiques à TPM2 ont été intégrées, conformément au TCG 1.3x.
SELinux
Correction d’une erreur avec SELinux qui empêchait par défaut le montage de sous‐volumes, alors que l’action sur le volume initial/principal a déjà été vérifiée et autorisée. Ceci causait des problèmes avec l’auto‐monteur automount, AutoFS, et NFS. Dorénavant, lorsqu’un sous‐volume présente un drapeau MS_SUBMOUNT, SELinux autorise son montage.
SECCOMP
Amélioration pour le système SECCOMP : si un conteneur demande, par exemple, un init_module(), alors SECCOMP va analyser l’image du module et charger le correspondant côté hôte. Autre cas, autre exemple : un conteneur n’a pas accès à mknode(), et personne ne veut d’un système de liste blanche pour des usages légitimes (de type /dev/null ou /dev/zero) et mount a déjà tout le nécessaire pour répondre à ce besoin. Une trap SECCOMP a donc été ajoutée pour l’espace utilisateur afin de notifier une autre tâche qu’un filtre SECCOMP particulier vient d’être déclenché. Concrètement, SECCOMP peut donc maintenant déléguer des politiques en espace utilisateur.
Chiffrement NHPoly1305, XChaCha12 et XChaCha20
Les algorithmes de chiffrement NHPoly1305, XChaCha12 (là surtout pour Adiantum) et XChaCha20 ont été intégrés. Ce document (en anglais) sur cr.yp.to, présente assez simplement les informations sur ChaCha. La gestion de l’accélération matérielle pour ces mêmes algorithmes a été ajoutée dans le pilote CCAM (crypto_dev_fsl_caam).
Chiffrement AEAD pour le pilote Nitrox
Ajout de l’algorithme AEAD pour le pilote Nitrox, utilisé par exemple sur certaine cartes Marvell, aussi dans une architecture « LiquidIO IPSec » (via Cavium) avec certaines cartes réseau du même fabricant.
ARM TrustZone CryptoCell
L’ARM TrustZone CryptoCell 703, édition chinoise du 713, car n’intégrant que les algorithmes validés par l’office chinois OSCCA, est intégré. Sa version « complète » 713 également. Voir cette ressource pour une comparaison rapide.
kexec
kexec est une ancienne capacité de charger un second noyau en mémoire vive, pour réamorcer le système dessus sans passer par les phases d’initialisation des BIOS, micrologiciels et EFI longues, très longues, de certaines machines.
kexec_load_file() tient maintenant compte du nouveau trousseau de clefs nommé .plateform de SecureBoot. Il est aussi utile pour d’éventuels modules de sécurité qui peuvent utiliser ce nouveau trousseau pour vérifier, autoriser et interdire les images noyau chargées, demandées par un appel kexec_load_file().
Plaisirs d’administrateurs système
Les administrateurs système bénéficient des nouveautés suivantes :
- l’ajout de deux marques spécifiques dans le système fanotify permettant de distinguer une exécution :
fan_open_exec et fan_open_exec_perm — tous les administrateurs système utilisant ce sous‐système via des utilitaires tels qu’inotify, incron et audit en seront ravis ;
- l’activation dans la hiérarchie par défaut d’un contrôleur CPUSET, concernant la prise en charge des Cgroups version 2 ; introduit il y a plus de dix ans, mais optionnel et laissé à la discrétion des admins, il fait maintenant son apparition dans une configuration « de base », en options minimales — certaines de ses possibilités pourraient à l’avenir migrer dans le contrôleur Cgroup de mémoire ou le contrôleur Cgroup de processeur ;
- l’ajout d’une possibilité de configuration des informations affichées lors d’une panique, grâce au nouveau panic_print.
Périphériques et pilotes
NVMe over Fabric
L’implémentation du NVMe over Fabric (NVMe pour « mémoire vive non volatile via bus PCI Express ») : concrètement il s’agit de s’affranchir des limites du port PCI Express en termes de distance physique, et de mettre à disposition du système des NVMe lointains via les réseaux TCP/IP.
Audio
Du côté du son, dans le noyau, nouvelles prises en charge et améliorations habituelles dans la pile générique HD_AUDIO, ainsi que pas mal de boulot sur les systèmes monopuces (SoC) présentés sur différents connecteurs, mais également une gestion préliminaire du AK4118 .
Pilotes de cartes graphiques
AMD et sa Radeon VII, semble bien être le meilleur choix pour les joueurs libristes et plus généralement de tous les joueurs sous GNU/Linux. Cette carte et son pilote libre amdgpu, accompagnée de Mesa 3D, accroche en performance une NVIDIA RTX 2080 avec son pilote propriétaire. OK ? OK !
AMD
- gestion du FreeSync, les fréquences dynamiques de rafraîchissement d’écran (permettant d’éviter certains effets visuels indésirables et aussi d’alléger la consommation), dans sa version « FreeSync 2 HDR », pour le pilote AMDGPU, et aussi un correctif, supprimant un petit bogue, accepté en toute dernière minute ;
- la réinitialisation du processeur graphique est fonctionnelle pour les CI, VI et Soc15, mais aussi sur les processeurs graphiques intégrés aux cartes mères (dGPU pour discrete GPU) ; si un traitement atteint un délai de grâce, le processeur graphique peut être réinitialisé, sans autre problème ;
- gestion pour l’espace utilisateur (via sysfs) de l’exposition des adresses mémoire des pages dites « BO doorbells » (un lien explicatif, bien qu’ancien et n’ayant pas de rapport direct avec cette nouvelle prise en charge, historique et intéressant à lire) ;
- gestion de la DCC (Delta Color Compression) : jusqu’à présent ce n’était pas manipulable en espace utilisateur, ce correctif l’active et l’expose à la fois pour la libdrm et l’AMDGPUDM, et ceci sans ajouter d’appels
ioctl() supplémentaires, ce qui devrait impacter favorablement les performances et la gestion de l’énergie ;
- prise en charge des Vega 12 et Polaris 12 pour KFD (kernel fusion driver, issu de HSA/Compute) ; d’autres Vega, dont Vega 20, arrivent au pas de charge — lire cet ancien commit pour en savoir plus, aussi sur la fusion de KFD dans AMDGPU ;
- et quelques autres, dont une mise à jour de micrologiciels SMU pour quelques variantes des GFX9, la gestion du PowerPlay pour les nouvelles Polaris, ajout de l’identifiant PCI pour les dernières Vega M, mais aussi un raffinement correctif pour l’amorçage « seamless » (un « amorçage du système silencieux et parfait visuellement ») avec les processeurs graphiques intégrés aux cartes mères (dGPU).
Intel
- ajout de l’identifiant PCI pour les dernières Amber Lake ;
- gestion des espaces colorimétriques YCbCr 4:2:0 et 4:4:4 pour les puces LPSCon par le pilote i915 et ajout de la transmission des informations AVI (la spécification semble si compliquée que de nombreux vendeurs de puces LPSCon le font chacun à leur manière, nous avons donc là à la fois un modèle générique et des subtilités pour chaque marque de LPSCon) ;
- et quelques autres petites améliorations, par exemple le mélange du plan Alpha, il pouvait y avoir des erreurs lors de l’usage d’une transparence totale ou a contrario d’une opacité totale.
NVIDIA et autres
De nombreuses autres cartes graphiques bénéficient d’améliorations. Nouveau ajoute le gestion initiale de la gestion des modes d’affichage (modsetting) pour la nouvelle génération des NVIDIA Turing 104 et 106. Les NVIDIA Tegra 186 et 194 bénéficient maintenant de l’audio via le port HDMI. Le Plan Alpha est intégré aux Exynos. VMWGFX gère maintenant la commutation de page (page flipping). Les Rockchips, MALI, Sun4Xi et Meson ne sont pas en reste.
Autres améliorations
- gestion de la compression de flux dynamique DSC (dynamic stream compression) des générations 10 et 11 des displays ports et external display ports, selon la norme VESA DP 1.4 ;
- prise en charge générique à un équivalent à ci‐dessus, pour le port HDMI — voir ce commit initial.
Réseau
Pas moins de 36 pilotes reçoivent des correctifs et améliorations. Une véritable tempête. On notera particulièrement parmi ceux‐ci :
- côté professionnel, les Mellanox gérées par mlx5 (carte ConnectX de 5e génération) reçoivent seize améliorations : GRE, tunnels au travers de VLAN tc, améliorations du DEVX et de ses commandes spécifiques, implémentation de l’IBTA CapabilityMask2, etc. — notons que la configuration de ces cartes est aisée avec le paquet mstflint et sa commande
msfconfig ;
- côté grand public, de nouvelles cartes sont désormais gérées par
iwlwifi : les 9461, 9462, 9560 et la série dite killer ; les Broadcom sont également de la partie, avec pas moins de neuf améliorations recensées par votre serviteur, dont la 4354 pour le brcmfmac (dont il est souvent question de nos jours : c’est fait) ;
- l’arrivée de l’autonégociation pour la 5G (et la 2,5G) pour le PHY.
Enfin, et ce n’est pas la moindre des améliorations, le protocole UDP reçoit le support du Generic Receive Offload (GRO), voir ce premier commit pour cette série. Le sujet est ancien et a connu semble‐t‐il plusieurs propositions correctives. Cela impacte les performances du protocole UDP, dans un contexte général d’augmentation de la bande passante disponible et d’augmentation de la puissance processeur, avec une MTU par défaut ancestrale et/mais une PMTU ne fonctionne pas dans la plupart des cas pour cause de réponse ICMP plus ou moins autorisée ou traitée, et où la segmentation en paquets devient parfois et malgré tout un goulot d’étranglement. GRO semble supérieur au couple LSO‐LRO et est maintenant géré par de nombreuses cartes réseaux. Concrètement, un ensemble de paquets UDP va traverser la pile en une seule unité, faisant ainsi une seule transaction pour l’espace utilisateur, et ceci sans modifier ni fusionner lesdits paquets UDP de l’ensemble.
Systèmes de fichiers
BinderFS
On note l’arrivée de BinderFS, un pseudo‐système de fichiers dédié pour l’IPC « binder » d’Android.
Binder est un dispositif ancien dans Android, et depuis Android O (Oreo, en 2017) toute la communication avec la HAL (hardware abstraction layer) et le cadriciel Android se fait avec lui, et des améliorations importantes ont été apportées, notamment avec l’utilisation des entrées‐sorties vectorisées.
« Qui contrôle l’IPC contrôle le Droid ». Le problème avec Binder est qu’il n’existe pas en tant que module pour le noyau vanilla (AOSP uniquement), d’une part, et d’autre part le nombre de devices disponibles est fixé… à la compilation. L’objectif de BinderFS sur Linux est de permettre l’utilisation de Binder dans des espaces de noms d’IPC (IPC namespace), donc de pouvoir en avoir plusieurs en même temps, isolés les uns des autres, et de permettre l’allocation dynamique du nombre de devices disponibles.
Pour mémoire, IPC namespace a apporté la capacité d’utiliser des IPC (communications inter‐processus) à l’intérieur d’un espace de noms, donc de les isoler pour y proposer un nombre restreint et privé d’objets IPC. Le cas typique d’usage est l’utilisation de conteneurs. Chaque nouvel espace de noms d’IPC va ici pouvoir monter une nouvelle instance de BinderFS, disposant donc de son propre dispositif de contrôle Binder ! Avec tout ce que propose ce fameux /dev/binder-control, isolé et sans limite fixée sur le nombre de devices. Il est ainsi possible de lancer plusieurs couches Android simultanément, sur un même noyau et vanilla. Sans couche de virtualisation, juste comme ça. « C’est fou ! » « Oui, mais vous aimez ».
Adiantum
Adiantum fait son apparition, il s’agit de chiffrement pour des appareils ne disposant pas des instructions AES (typiquement les téléphones que l’on trouve dans les pays dit émergents). C’est une bonne nouvelle pour nos amis là‐bas !
Btrfs
Btrfs dispose maintenant de la gestion de l’espace d’échange mémoire (swap), et non ce n’est pas une blague.
CIFS/SMB
Du côté de CIFS, c’est l’arrivée du cache et du failover (basculement) pour le DFS (Distributed File System, système distribué de fichiers sous CIFS), permettant aux clients de se reconnecter de manière transparente à un autre serveur CIFS, servant le ou les mêmes montages, si le premier serveur utilisé n’est plus disponible. Pour mémoire, il s’agit d’une des deux fonctions essentielles apportées par DFS, avec le balancement de charges entre serveurs. Le DFS (côté Windows) propose en plus une tambouille de liens symboliques pour présenter à l’exportation une autre racine que la racine réelle (rendant ainsi la vue côté client différente d’un client à un autre si l’administrateur le veut). Et CIFS, dans ses attributs étendus (xattr), dispose (enfin ?) d’un assemblage (compound), permettant ainsi de réduire la charge réseau (diminution des aller‐retours d’informations : on embarque tout dans une seule requête de plus grande taille) et d’améliorer les performances CIFS pour ce point.
AutoFS
Un changement qui devrait avoir toute votre attention concernant AutoFS : le retour de l’option strictexpire. Elle résolvait un problème lorsque les auto‐montages n’expirent pas, par exemple avec des accès « agressifs » (comprendre : normaux) par les clients. Ce correctif a ensuite été retiré car il entrainait, dans de larges environnements avec de nombreux clients, de nombreuses requêtes inutiles de montage donc une charge importante pour le serveur (quand les clients étaient laissés en configuration par défaut avec une valeur par défaut pour le temps sans accès avant démontage). Ce correctif marque le retour de cette option.
Virtualisation
Côté Virtualisation on notera entre autres :
- l’arrivée de la fonction « Processor Trace » d’Intel dans KVM, pour ses machines virtuelles invitées ; la gestion d’IPT date de plusieurs années et permet de tracer l’activité (d’une application, par exemple) sans surcoût pour les performances, elle est maintenant mise à disposition pour la virtualisation ;
- pas mal d’améliorations pour VirtIO :
- prise en charge de la configuration du Large Receive Offload (LRO, approche similaire aux Jumbos Frames), l’ajout de la gestion du discard (trim) sur le pilote virtio_blk et l’activation lorsque le périphérique déclare ces options,
- l’ajout de la gestion l’EDID (petit binaire contenu dans chaque écran et envoyé au système pour déclarer ses caractéristiques) pour le pilote virtio_gpu,
- la modification du côté de la synchronisation avec un descripteur de fichier sync_file renvoyé à l’espace utilisateur, comprenant l’appel de fin de synchronisation reçu ;
- l’ajout du « dirty log reprotect » pour KVM : l’idée semble être de libérer le verrou mmu_lock le plus tôt possible, pour cela le get_dirty_log n’envoie plus de page protégée en écriture, c’est l’espace utilisateur qui se charge de nettoyer avant usage des nouvelles infos présentées.
Statistiques
Nous vous invitons simplement à lire les informations collectées par Jonathan Corbet pour LWN.net pour la RC-7. L’Europe arrive largement en tête.
Autour du noyau
Du côté de la Fondation Linux, qui s’occupe de bien d’autres choses que du noyau, les nouvelles les plus récentes sont :
- pas moins de 22 nouveaux membres rejoignent la Fondation ;
- le Projet ELISA, Enabling Linux In SAfety critical systems, est lancé ; un effort commun (BMW, Toyota, Linutroniks et KUKA viennent de rejoindre le projet) afin de simplifier le développement d’applications critiques (où la vie humaine peut être en jeu) basées sur le noyau Linux ; le but n’est pas une nouveauté en soi, il s’agit d’une nouvelle alliance ouverte ;
- Automotive Grade Linux, autre alliance ouverte, publie une API pour la reconnaissance vocale ;
- lancement de l’Academy Software Foundation par la Fondation Linux et l’« Academy of Motion Picture Arts and Sciences », comprenant entre autres Animal Logic, Autodesk, Blue Sky Studios, Cisco, DNEG, DreamWorks Animation, Epic Games, Foundry, Google Cloud, Intel, SideFX, The Walt Disney Studios, et Weta Digital. Que du beau monde ? ;-)
Pour terminer
Un nouvel utilitaire permet la production d’un fichier configure_commands au format JSON. À l‘instar de libtooling du projet Clang/LLVM et de ce que font des outils tels que CMake ou Bazel, cet utilitaire va chercher les .o.cmd dans l’arborescence du noyau (contenant l’ensemble des informations nécessaires à la compilation), en extrait ces commandes de compilation et produit un fichier en sortie unique compile_commands.json qui pourra être utilisé à loisir par tout outil basé sur la libtooling. make config; make -j$(nproc); scripts/gen_compile_commands.py.
