Les nouveautés

Arch

CPU

Ces dernières années les supercalculateurs ont dépassé le nombre de 4 000 cœurs de calcul, le nombre de processeurs maximum se voit donc augmenté de 4 096 à 8 192.

La présentation de la topologie matérielle au démarrage du noyau a également subi un petit lifting. Avant, le système nous présentait les informations sous cette forme :

smpboot: Booting Node   0, Processors  #1 #2 #3 OK
 smpboot: Booting Node   1, Processors  #4 #5 #6 #7 OK
 smpboot: Booting Node   2, Processors  #8 #9 #10 #11 OK
 smpboot: Booting Node   3, Processors  #12 #13 #14 #15 OK
 Brought up 16 CPUs

Dès cette version, ces mêmes informations seront affichées de cette manière :

x86: Booting SMP configuration:
 .... node  #0, CPUs:        #1  #2  #3
 .... node  #1, CPUs:    #4  #5  #6  #7
 .... node  #2, CPUs:    #8  #9 #10 #11
 .... node  #3, CPUs:   #12 #13 #14 #15
 x86: Booted up 4 nodes, 16 CPUs"

Logging / Debug

Perf

Dans cette version, le système de compilation de l’outil perf se voit amélioré. Désormais, la phase de compilation nécessite beaucoup moins d’étapes de la part de l’utilisateur.

cd tools/perf
make install

De plus, celle‐ci s’exécute beaucoup plus rapidement car le système de compilation détecte le nombre de cœurs à la volée et lance une compilation en parallèle en conséquence.

Pour mémoire, perf est un outil de profilage dans Linux qui permet de superviser facilement les compteurs de performance. Les compteurs de performance sont des registres spéciaux dans le processeur qui permettent de compter les événements matériels qui ont lieu lorsque vous exécutez du code : le nombre de défauts de cache, le nombre d’instructions exécutées, les prédictions de branchements correctes ou incorrectes, etc.

CPER

La prise en charge de CPER (UEFI Common Platform Error Record) ou également appelé enhanced MCA logging, disponible dans les derniers processeurs Xeon, a été ajoutée.

Ces dernières années, le nombre de transistors dans les micro‐processeurs et les chipsets mémoires a augmenté très rapidement. Le matériel est de plus en plus miniaturisé et contient de plus en plus de transistors. Ceci, avec la possibilité d’être touché par un rayon cosmique, augmente donc les risques de corruption de données. De plus, la défaillance matérielle reste toujours possible. Les chipsets modernes peuvent corriger certaines de ces erreurs par eux‐mêmes (sommes de contrôle ECC), mais il est parfois nécessaire que le système d’exploitation soit notifié de ce genre de problème car le matériel ne peut pas le corriger lui‐même.

C’est pour cette raison que les processeurs modernes mettent à disposition un mécanisme appelé MCA (Machine Check Architecture) qui permet, entre autres, au processeur de notifier le noyau des erreurs matérielles telles que les erreurs ECC, erreurs de parités, erreurs de caches, etc. Ce mécanisme est à base de registres spéciaux, dit MSR (Machine Specific Registers), afin de stocker les informations sur les erreurs rencontrées et de permettre au système de les traiter. Malheureusement les MSR sont extrêmement dépendants de l’architecture, sont limités en taille et sont parfois très difficiles à interpréter.

CPER est une technologie d’enregistrement d’erreurs MCA gérée par le micrologiciel UEFI. C’est maintenant le micrologiciel qui va directement collecter les messages d’erreurs, les interpréter et les projeter en mémoire physique afin que le système d’exploitation puisse les analyser. Ceci va permettre, entre autres, de disposer d’un système de vérification d’architecture beaucoup plus portable, plus facile à maintenir et beaucoup plus riche en termes de rapports d’erreurs.

Pour plus d’information je vous invite à lire l’article Machine check handling on Linux et le white paper d’Intel sur le MCA avancé dans les processeurs Xeon.

Ktap

L'outil ktap a presque été intégré dans cette version. Une première fusion avait été faite avant d'être retirée, jugeant que la procédure de revue n'avait pas été respectée et que certaines rectifications devraient être faites avant que cela ne se produise. Son auteur a d'ailleurs dit qu'il était prêt à les faire. Peut-être une fusion dans la 3.14 ?

ktap est un outil de débogage et de traçage dynamique. Il s'agit d'une machine virtuelle Lua embarquée dans le noyau linux qui vient s'interfacer avec les outils de traçage existant. L'un de ses avantages est sa capacité à pouvoir injecter un script Lua de débogage directement dans le noyau, sans avoir à compiler quoi que ce soit et de permettre de créer des routines de débogage sophistiquées simplement et rapidement.

Earlyprintk avec UEFI

La gestion du earlyprintk pour UEFI vient d'être ajoutée. Ceci permet de logger des messages par le biais de la fonction printk du noyau beaucoup plus tôt en déléguant l'affichage au framebuffer de UEFI durant le début de la phase de démarrage. Utiliser le framebuffer vesa n'étant pas possible sur les systèmes UEFI, il était donc nécessaire d'utiliser un lien série matériel pour pouvoir déboguer le noyau avant que le pilote graphique ne soit chargé. Les liens série matériels étant de plus en plus rares sur les ordinateurs récents, cette fonctionnalité est la bienvenue.

printk est une fonction dans le noyau, comme printf, mais qui permet de logger des messages avec différents niveaux de criticités dans la console du noyau. Console dont vous pouvez ensuite retrouver le contenu à l'aide de la commande "dmesg".

Lockdep

La prise en charge de seqcount/seqlocks a été ajoutée à lockdep.

Lockdep est le validateur de verrouillage du noyau, c'est un outil de débogage extrêmement utile. Il permet en ajoutant un petite surcouche de code autour de chaque structure de donnée bloquante (spinlock, sémaphore etc) de savoir lorsqu'un verrou est pris ou relâché ou collecte des informations critiques comme lorsqu'un processeur gère une interruption après avoir pris un verrou. Il permet également de détecter les cycles. Depuis son introduction en 2006 il a permis de supprimer énormément de bugs et de deadlock dans le système. La prise en charge dans cette version a d'ailleurs permis de corriger quelques bogues.

Ordonnanceurs / timers

Équilibrage NUMA automatique

Dans cette version, la gestion des politiques d'ordonnancement pour les architectures NUMA a été améliorée. Il est maintenant possible de placer un processus à côté de sa mémoire ou encore de demander au système de placer deux processus qui partagent une page mémoire dans un même nœud. Des appels systèmes sysctl ont été ajoutés afin de pouvoir activer/désactiver ces politiques d'ordonnancement, voir ce commit de documentation.

NUMA (Non Uniform Memory Access) est un système d'architecture sur les machines multi-cœurs contemporaines qui permet de regrouper les cœurs de calculs par nœud. Les différentes zones mémoires sont ensuite séparées et accédées par différents bus placés respectivement sur chacun des nœuds. Ainsi, dans les systèmes disposant de beaucoup de cœurs, cela évite d'avoir un goulet d'étranglement sur le bus mémoire et d'impacter les performances de temps d'accès mémoire. L'impact visible de cette technique est que chaque cœur a une zone mémoire qui lui est directement attachée et qui est la plus performante.
De ce fait en fonction de la zone mémoire à laquelle un processus accède, sa mémoire locale, ou la mémoire distante, ses performances en seront changées en conséquence. Il est donc important qu'un système d'exploitation tienne compte de cette topologie matérielle afin de placer un processus en cours d’exécution sur le bon nœud en fonction de la partie de la mémoire à laquelle il accède.

Pour plus de détails vous pouvez consulter cet article.

Power / ACPI

La nouveauté principale liée à la gestion d'énergie est l'ajout du framework de limitation de consommation. Celui-ci a pour objectif de limiter et de pouvoir répartir la consommation énergétique entre de multiples matériels.

Pour l'instant, cette gestion semble limitée à Intel et sa technologie RAPL (Running Average Power Limit). À la base de RAPL se trouve un système de calcul de consommation énergétique basé sur un modèle du processeur et une instrumentation matérielle pour connaître quels blocs sont actifs à quel moment. À partir de cette information, il est ensuite possible de réduire la fréquence moyenne reçue par le processeur en ne laissant passer, par exemple, que 80% des tics d'horloge. Cette réduction de fréquence permet de réduire la consommation moyenne du processeur et peut être modulée de sorte à ce que le processeur consomme exactement ce que l'OS lui a demandé de consommer. Cette technique est très efficace pour les petits ajustements et pour sa réactivité face aux pics de charge mais est sous-optimale car elle nécessite une tension d'alimentation supérieure à ce qui était vraiment nécessaire pour atteindre le même niveau de performance. La tension d'alimentation est le principal facteur derrière la fuite de courant des transistors (consommation statique). Cette consommation statique participe à hauteur d'environ 50% de la consommation globale d'un processeur moderne. Une fois RAPL combiné avec le changement de niveau de performance reprogrammant le contrôleur de tension et les générateurs d'horloges, RAPL permet de limiter très rapidement la consommation pour respecter une consigne tout en gardant une efficience proche de l'optimal.
Intel utilise RAPL pour contrôler chaque cœur du processeur ainsi que la mémoire.

NVIDIA dispose d'un système équivalent depuis les Geforce 8 mais ne s'en est jamais servi. Des indices laissent à penser qu'il pourrait cependant s'en servir pour les Tegra K1. Nouveau ne peut pas vraiment s'en servir car il faudrait calculer les paramètres du modèle matériel de la carte. C'est théoriquement possible mais ça nécessite beaucoup de travail et du matériel spécialisé que l'équipe de Nouveau n'a pas. Nouveau devrait cependant pouvoir utiliser un système plus lent à réagir sur les cartes équipée d'une sonde matérielle de consommation énergétique lorsque le changement de fréquence dynamique sera géré. La gestion sera cependant réservée aux cartes milieu et haut de gamme Kepler.

Pour plus d'informations concernant ce framework, vous pouvez consulter cette présentation hébergée par la Linux Foundation.

Le reste du pull request ACPI est majoritairement composé de correction de bogues et d'améliorations liées à cpufreq, l'implémentation du DVFS (Dynamic Voltage/Frequency Scaling, changement de niveau de performance en fonction de la charge) pour les CPU.

Pilotes graphiques libres

Direct Rendering Manager (DRM)

Peu de nouveautés dans DRM pour cette nouvelle version. La principale est l'extension de l'interface pour autoriser les clients à activer/désactiver des capacités. Cette extension a directement été utilisée pour exposer la 3D Stéréo, quand les écrans la gèrent. Pour le reste, on trouve une gestion des fichiers sysfs plus résistante au chargement/déchargement des pilotes à chaud, une amélioration de la précision des timestamps des événements lié au scanout et beaucoup de correction de bogues.

Cette nouvelle version a été l'occasion de rappeler les règles pour l'apport de nouvelles fonctionnalités lorsque des modifications dans Linux, libdrm et mesa (responsable de l'accélération 3D libre) sont nécessaires. Ce rappel à l'ordre a été lancé par Dave Airlie, mainteneur DRM, après qu'un développeur Intel ait commité dans libdrm avant que son patch pour Linux n'ait été accepté. Ce commit a directement été annulé avec un court avertissement qui a été suivi par un courriel envoyé sur la liste de diffusion du projet mesa pour donner plus de détails. Une courte discussion a suivi, certaines personnes critiquant l'idée que libdrm n'ait pas de mainteneur alors que d'autres trouvent que la situation actuelle est parfaite tant qu'une règle simple est respectée. Cette règle est que la prise en charge de cette fonctionnalité doit en premier lieu être ajoutée dans une branche officielle du noyau (au moins drm-next) avant de pouvoir ajouter la gestion pour cette fonctionnalité dans libdrm, puis dans mesa. C'est ce second choix qui a été retenu.

Adreno (pilote msm)

Msm, le pilote écrit par Rob Clark pour les GPU ARM Adreno que l'on trouve dans tous les processeurs Snapdragon de Qualcomm, se voit doté d'une prise en charge pour les render nodes, prime et des KMS planes.

Prime est l'implémentation libre de la technologie Optimus qui permet aux pilotes graphiques de pouvoir collaborer de façon à pouvoir effectuer le rendu d'une image sur un GPU et l'afficher sur un autre.

Les KMS planes sont à la base du compositing matériel. Chaque "plane" est une image RVBA (ou équivalent) qui sera fondue avec les autres "plane" matériellement au lieu d'utiliser les shaders OpenGL. Cela permet d'augmenter les performances et/ou de diminuer la consommation énergétique.

Pour plus d'informations, vous pouvez regarder le pull request de Rob Clark.

AMD/ATI (pilote radeon)

Cette nouvelle version du pilote radeon pour les GPU AMD/ATI active enfin par défaut le son pour les écrans HDMI. Il ajoute aussi la gestion complète (modesetting, décodage vidéo, gestion d'énergie) pour la famille de carte Hawaii dont les premières cartes sont sorties en octobre 2013.

Coté gestion d'énergie, cette nouvelle version apporte la gestion de la mise en veille complète des GPU discrets qui ne sont pas utilisées dans une machine gérant le PowerXpress (équivalent d'AMD à la technologie Optimus d'NVIDIA). Elle apporte aussi la gestion du DPM (Dynamic Power Management) à plus de cartes et notamment aux familles Southern Island et Hawaii.

Niveau performance, cette nouvelle version apporte un énorme gain de 500 à 750% suivant les tâches sur les GPU de la famille Southern Island et Hawaii. La raison pour cette subite amélioration tient au fait que seul le premier moteur de shader était activé. Ce problème a été diagnostiqué et corrigé par le développeur AMD Marek Olšák. Cette nouvelle version du pilote est donc plutôt bénéfique pour les utilisateurs de cartes graphiques récentes AMD.

Armada (pilote armada)

Un nouveau pilote a fait son apparition dans DRM afin de gérer les GPU des SoCs Marvell Armada 510.

Ce pilote est extrêmement complet pour une première version puisqu'il gère deux écrans LCD, les KMS planes, le pageflipping pour les tampons graphiques dédiés à l'affichage et prime pour le partage de tampons graphiques entre clients et pilotes. Cependant, la fonctionnalité la plus importante est la gestion des tampons graphiques partagés par SHM car ils permettent à Armada et au pilote Open Source etna_viv (Vivante) de fournir une accélération graphique 3D libre.

D'après son développeur, bien que ce pilote soit à destination des Armada 510, la gestion de la série 610 devrait être facile à ajouter.

Intel (pilote i915)

Beaucoup de nouveautés chez Intel avec notamment l'introduction officielle de la gestion des processeurs Broadwell qui devraient être disponibles à la vente au 3ème trimestre 2014. Cette prise en charge est pour l'instant cachée derrière une option de compilation mais à moins que vous ne travailliez pour Intel, vous ne devriez pas en avoir besoin. Une prise en charge suffisante pour être utilisable arrivera dans Linux 3.14.

Une autre nouveauté est le début de la gestion du Display Serial Interface (DSI) de l'alliance Mobile Industry Processor Interface (MIPI). Ce nouveau type de communication a pour but de réduire le coût des systèmes mobiles embarquant des écrans. DSI est disponible sur le Raspberry Pi. Toujours coté affichage, une prise en charge basique des écrans 3D a été ajoutée. La prise en charge grand public devrait être disponible assez rapidement dans Wayland (ce qui permettra de voir les engrenages de eglgears tourner en véritable 3D !) et la gestion de la mise à jour atomique des sprites (pour le tatouage numérique) et de la plane principale. Pour finir, le noyau exporte maintenant via debugfs le CRC des images après toutes les étapes de rendu (curseur, planes, sprites, correction de couleurs et changement d'échelle). Cela va permettre d'automatiser des tests de rendu graphique. Un premier test sur les curseurs a déjà était écrit et a permis d'identifier et de résoudre plusieurs bugs.

Du coté de la gestion énergétique, Intel n'a pas chômé en retravaillant son code de gestion du power gating et en ajoutant notamment la gestion du SWSCI, un framework de gestion d'énergie pour les processeurs graphiques intégrés Intel. Cette gestion est nécessaire majoritairement pour Haswell dont le code de référence ACPI est très dépendant de SWSCI. Intel a également apporté la gestion du boost/deboost logiciel qui devrait améliorer les performances et réduire la consommation dans les cas où la charge est relativement faible mais subit des forts pics d'activité comme lors de la navigation sur le web.

Une partie des patchs nécessaires pour l'ajout du Per-Process Graphic Translation Table (PPGTT) a aussi été intégrée dans cette version de Linux. Cela permet à différents processus graphiques de ne pas partager le même espace d'adressage graphique ce qui devrait augmenter l'isolation entres les différentes applications. PPGTT sera disponible à terme sur les GPU Ivy Bridge, Haswell, et Broadwell. Pour plus d'informations, vous pouvez consulter la série de patch associée.

NVIDIA (pilote nouveau)

Dans cette nouvelle version du noyau, le pilote communautaire pour cartes graphiques NVIDIA n'a pas reçu beaucoup d'améliorations visibles si ce n'est l'ajout de la gestion du modesetting pour le chipset NV108/GK208. La gestion complète de la carte sera introduite dans la version 3.14 du noyau.

La prise en charge des interruptions MSI (Message Signaled Interrupts) a été activée par défaut afin de corriger des problèmes sur certaines nouvelles cartes pour lesquelles la méthode traditionnelle de gestion des interruptions n'était pas fiable. À l'inverse, avant cette version, plusieurs cartes ne géraient pas les interruptions MSI très bien ce qui rendait le démarrage impossible. NVIDIA a été contacté afin d'avoir des informations sur un potentiel errata matériel. Entre temps, Ben Skeggs a investigué le problème et a trouvé par rétro-ingénierie, une solution pour les cartes problématiques connues. NVIDIA a confirmé la solution et a permis d'améliorer la gestion pour d'autres cartes qui n'étaient pas connues pour avoir de problèmes. L'équipe de Nouveau a ensuite découvert que les cartes nvaa et nvac ne géraient pas bien les interruptions MSI, elles ont donc été désactivées. Depuis, il n'y a plus eu de rapport de bug sur ce sujet.

Du coté vidéo, le page-flipping a été retravaillé pour corriger des bogues qui duraient depuis plusieurs versions. Nouveau devrait donc moins souffrir du problème de tearing. La gestion de PMPEG a aussi été améliorée pour prendre en charge les NV40-NV44. Les NV10 ont également reçu la gestion des planes KMS permettant de faire de la composition (compositing) matériel.

Le gros du travail dans cette nouvelle version est lié à la gestion d'énergie, effectué par Ben Skeggs. Toute l'infrastructure a été repensée pour pouvoir prendre en charge le changement de fréquence dynamique, le clock gating et le power gating. Nouveau remplace maintenant le microcode du processeur de gestion d'énergie PDAEMON/PPWR ce qui veut dire que le pilote est maintenant responsable de la gestion du ventilateur sur Fermi. Ce microcode, écrit en assembleur Falcon/FµC, est un petit RTOS qui permettra de décharger le processeur principal pour l'acquisition et le suivi de la charge de la carte, de la régulation du ventilateur et de la consommation.

Outre le refactoring du code, Ben Skeggs a aussi corrigé beaucoup de bogues dans le changement de fréquence des moteurs d'exécution et de la sélection de la tension d'alimentation. Le changement de fréquence de la mémoire a également reçu beaucoup de commits bien que le résultat ne soit toujours pas utilisable et ne le sera probablement pas avant plusieurs versions du noyau pour la plupart des cartes.

Pour en finir avec la gestion d'énergie, la gestion complète du changement de fréquence manuel pour les nvaa/ac (ION) a ensuite été apportée par Roy Spliet. Ces chipsets sont intégrés et n'ont donc pas de mémoire vidéo. Ce sont actuellement les seuls chipsets pour lesquels le reclocking est officiellement pris en charge. Une prochaine version apportera le changement de fréquence dynamique mais aucun développeur ne travaille actuellement dessus pour les cartes n'intégrant pas PDAEMON/PPWR.

Poulsbo (pilote gma500)

Le pilote gma500 pour les processeurs graphiques basés sur les PowerVR SGX 535 (aussi connus sous le nom de Intel Poulsbo) a reçu les modifications nécessaires pour fermer un bug relatif à l'hibernation datant d'il y a plus d'un an.

Cette version apporte également la gestion d'SVDO aux Minnowboard (équivalentes aux Raspberry Pi, mais basées sur des processeurs Intel Atom et avec un connecteur SATA). SVDO (Serial Digital Video Out) est une technologie propriétaire d'Intel permettant d'ajouter des connexions VGA, DVI, SDTV, HDTV ou des tuners de télévisions à travers un bus PCI express à 16 voies.

Tegra (pilotes host1x et tegra)

Le pilote pour la version embarquée des GPU NVIDIA (Tegra), a été ré-architecturé pour être découpé en deux sous-parties, host1x et tegra.

Host1x est un contrôleur DMA qui permet d'envoyer des commandes en asynchrone à différents composants graphiques et multimedia et de les faire se synchroniser grâce à l'utilisation de fences. Pour plus d'information, vous pouvez lire la documentation d'NVIDIA à son sujet.

Tegra est le GPU qui effectue les calculs graphiques. Jusqu'à présent, la partie Tegra se trouvait avec host1x dans /drivers/gpu/host1x/. Elle a été déplacée dans /drivers/gpu/drm/tegra ce qui a permis de simplifier la procédure de démarrage de DRM.

La gestion de Tegra114 a ensuite été ajoutée dans les deux sous parties. Host1x a reçu les modifications nécessaires pour tenir compte d'un léger changement et de l'ajout d'un autre point de synchronisation. Tegra a lui aussi dû être légèrement modifié pour ajouter la gestion du contrôleur d'affichage et la prise en charge de l'HDMI.

Pour finir avec les nouveautés, la gestion de gr3d a finalement été fusionnée ce qui veut dire que toutes les pièces côté noyau sont présentes pour permettre l'accélération 3D dans l'espace utilisateur.

VMware (pilote vmwgfx)

Pour le GPU virtuel des machines virtuelles VMware, la prise en charge de prime a été ajoutée. Cette prise en charge n'est pas complète car elle ne permet pas le partage de tampons graphiques entre différents pilotes. C'est cependant suffisant pour permettre de gérer DRI3.

Réseau

nftables

nftables est maintenant utilisable directement avec le dernier noyau. Vous pouvez consulter son pull request.

Nftables est le successeur de iptables. Il permet de configurer le pare-feu de linux (netfilter). Rappelons qu'iptables et netfilter ont été développés en 2001 pour le noyau 2.4 et qu'iptables a peu évolué depuis. Iptables a beaucoup de limitations au niveau fonctionnel et au niveau du code : problème de la mise à jour des règles, de duplications de code qui entraînent des problèmes pour sa maintenance et pour les utilisateurs. Ainsi, pas mal de changements ont été entrepris pour nftables afin de résoudre cela tout en fournissant une compatibilité pour les utilisateurs d'iptables.

Son développement s'est fait en deux temps : le développement a commencé en 2008 jusqu'en 2009 par Patrick McHardy, le chef de projet de netfilter. Une version alpha du code a été présentée. Malheureusement, peu de monde a rejoint ce projet pour en finaliser le code. Le projet est alors resté en sommeil jusqu'en 2012 où son développement a repris grâce notamment à Pablo Neira Ayuso.

Pour plus de renseignements :

• La présentation de lwn.net en 2009 : un nouvel espoir
• Le blog d'Éric Leblond : nftables contre-attaque
• La présentation de lwn.net en 2013 : le retour de nftables
• Un article en français sur kernel-recipes.org d'Éric Leblond
• Le site officiel de nftables

En bref

• TCP Fast Open qui avait été ajouté dans Linux 3.7 est maintenant compilé par défaut ;
• IPv6 : amélioration de l'IPsec et ajout de GSO/TSO ;
• Mobile : ajout de l'implémentation de la couche pour la communication en champ proche (Near Field Communication, NFC) utile par exemple pour les terminaux de paiement ;
• Haute disponibilité :
  • amélioration de l'agrégation de liens (bonding) concernant le mode tourniquet (round-robin) et concernant la possibilité de mettre en place les options mode et active_slave via l'interface standard Netlink ;
  • ajout de l'implémentation du protocole de la redondance transparente haute-disponibilité (High-availability Seamless Redundancy, HSR). HSR fournit de la redondance de failover instantanée pour les réseaux ethernet. Cela demande une topologie en anneau (chaque nœud ayant deux interfaces réseaux). Ce protocole est adapté pour les applications qui requièrent de la haute-disponibilité avec un temps de réaction très court.

Pour plus d'information :

• Pour les anglophones ;
• Pour les germanophones.

Systèmes de fichiers

Une couche Multi File d'attente (Multi-Queue Block Layer) fait son apparition au sein du noyau. Celle-ci est destinée à améliorer les opérations d'entrées-sorties par unité de temps (IOPS) tout en réduisant la latence dans un système composé de multiples disques SSD et de plusieurs cœurs processeurs.

Le noyau devrait maintenant essayer de mieux répartir la charge pour chaque cœur processeur tout en autorisant plusieurs files d'attentes matérielles. On attend une augmentation des opérations d'entrées-sorties d'un facteur allant de 3,5 à 10, et une réduction de la latence d'un facteur 10 à 38.

Dans le même temps, il semblerait que certains systèmes de fichiers soient plus lents que dans la version 3.12 du noyau. La cause de cette régression reste, pour l'instant, inexpliquée.

Btrfs

Miao Xie a permis de nettoyer le code de Btrfs, tout en améliorant les performances du mécanisme de write-back.
Enfin, alors que Chris Mason (à l'origine de Btrfs lorsqu'il travaillait pour Oracle) quitte son actuel employeur, la société Fusion-io, pour aller travailler au sein de Facebook, Josef Bacik entre officiellement dans la liste des mainteneurs de Btrfs ; le travail de Chris Mason pour Btrfs ne changera quasiment pas.

F2FS

À côté des habituelles corrections de bogues, F2FS améliore son ramasse-miette et les procédures de son verrou global.

XFS & Ext4

Le code d'Ext4 est légèrement amélioré par quelques corrections de bogues tout en étant allégé. Quant à XFS, une partie de son code a été réusiné, et ses performances se sont améliorées.

Sécurité

Audit

Les processus disposant de la capacité CAP_AUDIT_CONTROL pourront remettre à zéro (en fait -1, la valeur signifiant indéfini) le loginuid. Une fois que les outils de création de conteneurs (systemd-nspawn, lxc, libvirt-lxc) auront été modifiés, cela permettra aux conteneurs de fonctionner correctement avec le système d'audit, ne nécessitant donc plus de le désactiver au démarrage. Commits : 1, 2.

Pour mieux comprendre ce changement, il faut revoir l'historique de loginuid. L'infrastructure d'audit permet, entre autres, de suivre les utilisateurs et les processus qu'ils lancent une fois qu'ils sont logués sur un système. Pour cela, l'UID utilisé lors du login est stocké (loginuid dans la structure task_struct) de façon indépendante de l'UID courant. Cela permet de suivre les utilisateurs même s'ils changent d'utilisateur ou passent en root avec sudo par exemple. Cette opération de stockage du loginuid doit être effectuée par le programme responsable du login d'un utilisateur sur un système. On utilise pour cela un module pam spécifique : pam_loginuid.so.

Au démarrage, les processus n'ont pas de loginuid défini (-1). Avant le noyau 3.3, il fallait disposer de la capacité CAP_AUDIT_CONTROL pour pouvoir changer le loginuid. Il était nécessaire d'autoriser ces changements même si un loginuid valide était déjà défini car sinon un administrateur relançant le démon sshd propagerait son loguinuid à tous les utilisateurs se loguant en ssh.

Mais ce n'est pas vraiment le comportement idéal, puisque l'on voudrait pouvoir définir ce loginuid uniquement lors du login et ne plus autoriser aucune modification. Le noyau 3.3 introduit l'option AUDIT_LOGINUID_IMMUTABLE qui autorise n'importe quel processus à définir initialement son loginuid sans avoir besoin de droits particuliers et empêche ensuite tout changement. Ceci est possible uniquement sur les systèmes utilisant systemd, car l'utilisateur ne lance ou relance plus lui même les services mais demande à systemd de le faire. Le démon sshd aura donc un loginuid non défini (hérité de systemd) et pourra le définir pour un utilisateur à la connexion. Si un administrateur lance un démon ssh à la main, le loginuid ne sera pas changé et l'on pourra donc tracer l'origine de ce démon.

Mais cette situation pose de nouveaux problèmes avec les conteneurs. En effet, cette fois les conteneurs sont lancés par un utilisateur, donc le loginuid est déjà défini, et les processus à l'intérieur du conteneur ne prenaient pas en compte cette situation. Les deux commits mentionnés ajoutent donc une interface qui contourne ce problème.

L'option AUDIT_LOGINUID_IMMUTABLE a aussi été retirée (commit), car jugée pas assez flexible. Une nouvelle option la remplace pour bloquer le changement de loginuid à partir de l'espace utilisateur.

IMA

Il est maintenant possible de signer les fichiers avec des algorithmes de hachage différents suivant l'importance accordée à l'intégrité du contenu par exemple. Pour ajouter cette fonctionnalité, il a été nécessaire, de modifier la gestion des templates IMA qui décrivent l'organisation des données dans l'attribut de sécurité IMA.

KEYS

Modification des espaces de nom utilisateur (user namespace) pour pouvoir avoir un trousseau de clés, stocké dans le noyau, distinct pour chaque espace de nom. Le trousseau de clés noyau fonctionne comme un cache et permet entre autres de stocker des clés de façon sûre et persistante jusqu'à leur expiration, même si l'utilisateur se déconnecte. Ce cache est particulièrement utile pour les tâches cron et kerberos.

Ces clés peuvent maintenant être de taille plus importante (potentiellement illimitée) et être swappées sur le disque dur.

Random

Suite à une analyse de la fonction chargée du mixage des sources d'entropie, une modification a été effectuée pour l'améliorer légèrement. Pour rappel, le noyau n'utilise pas directement les sources d'entropie dont il dispose pour générer des nombres aléatoires. Il mélange diverses sources pour s'assurer qu'une mauvaise source ne vienne pas réduire l'entropie finale obtenue. Cet article sur le blog de Cloudflare détaille le processus dans le noyau.

Le fonctionnement de /dev/random a été en partie revu : l'entropie est moins gaspillée, mieux estimée et les performances sont améliorées. Les architectures non x86 bénéficient de l'utilisation d'un registre qui ne peut pas être utilisé pour la mesure précise du temps mais qui peut apporter un peu d'entropie.

Le noyau affiche maintenant l'état d'initialisation de /dev/urandom et prévient s'il est utilisé avant qu'il soit initialisé correctement. Ceci est fait en prévision d'un possible futur changement de comportement : le blocage de /dev/urandom si l'initialisation n'est pas terminée.

D'autre modifications ont été effectuées pour /dev/urandom, elles sont détaillées dans ce mail récapitulatif. Des améliorations diverses et l'ajout du support pour de nouveaux générateurs de nombres aléatoires ont également été inclus (commit).

SELinux

Pour les systèmes de fichiers ne gérant pas les attributs étendus, un contexte SELinux est généré en fonction de la politique ou des options passées lors du montage. Une petite modification autorise maintenant le changement du contexte de sécurité d'un fichier lorsque celui-ci est dans un rootfs (ramfs).

La fonction chargée de la vérification de la validité de la partie multi-niveau d'un label de sécurité (MLS) a été fortement optimisée.

Ajout d'une capacité pour la politique indiquant que les opérations réseaux devront toujours être vérifiées par SELinux, même si les règles adéquates de filtrage et marquage des paquets ne sont pas chargées dans netfilter. Cela permet de protéger le système si les règles de filtrage ne peuvent pas être chargées à cause d'une erreur ou si elles sont vidées par un programme malicieux. La partie correspondante en userspace a déjà été mergée l'année dernière.

SMACK

Un nouveau mode d'accès a été introduit pour différencier la pose d'un verrou sur un fichier d'une opération d'écriture. En effet, la pose d'un verrou en lecture sur un fichier ne nécessite pas d'avoir les droits d'écriture sur celui-ci, juste les droits de lecture. Ainsi, deux programmes pourraient potentiellement discuter par l'intermédiaire d'un fichier dont ils ont tous les deux seulement accès en lecture. C'est un canal d'information caché, et typiquement le genre de situation que l'on souhaite éliminer dans le cadre d'un contrôle d'accès obligatoire. SMACK nécessitait donc d'avoir les droits en écriture (avec les labels SMACK, pas juste le DAC) pour pouvoir poser des verrous en lecture, ce qui cassait le comportement de nombreux programmes puisque c'était une situation inattendue (et la solution n'était pas acceptable d'un point de vue sécurité). Pour résoudre ce problème, le mode d'accès lock permet de poser des verrous en lecture, et il faut avoir l'accès write pour les poser aussi en écriture. Cela évite donc de donner trop de droits à un processus sur certains fichiers.

Le crochet (hook LSM) lié à ptrace a été précédemment séparé pour permettre un contrôle plus fin des opérations effectuées. SMACK n'en profitait pas totalement, c'est maintenant corrigé.

x86

Le noyau et l'espace utilisateur échangent couramment des données. Pour des raisons d'intégrité du noyau, il est important de vérifier que seules les données voulues par le noyau soient copiées en espace noyau. Pour des raisons de confidentialité, il est aussi important de vérifier que seules les données dont l'espace utilisateur a besoin soient rendues accessible à celui-ci. Pour ces raisons, le noyau a des tests pour vérifier les bornes des opérations de copie depuis/vers l'espace utilisateur. Jusqu'à présent, ces opérations étaient vérifiées statiquement, à la compilation. Ces tests étaient cependant pleins de faux positifs dans le cas où la taille des données copiées était dynamique, surtout lorsque l'option DEBUG_STRICT_USER_COPY_CHECKS était activée. Pour résoudre ce problème, les tests pour les tailles dynamiques ont été déportés à l'exécution.

Virtualisation

Hyper-V

La partie du pilote Hyper-V (l'hyperviseur de Windows) voit l'ajout d'un pilote de clavier.

KVM

Pour KVM, il y a un peu plus de changements, il est désormais possible d'avoir la virtualisation qui utilise l'émulation et l'hyperviseur en même temps sur le même noyau. Pour les processeurs Intel, la virtualisation imbriquée s'améliore et ARM gère les transparent huge page, une amélioration de l'overcommit et la prise en charge des invités gros-boutistes.

Il y a aussi une nouvelle interface pour connecter KVM à l'aide des VFIO, ce qui permet aux utilisateurs des NoSnoop PCI transactions d'avoir un invité qui peut exécuter les instructions WBINVD, utiles notamment pour les pilotes nVidia sur Windows.

Xen

Dans cette version, Xen a reçu beaucoup de corrections de bogues et deux fonctionnalités majeures. La première est un système de traçabilité qui a été ajouté au pilote Xen SWIOTLB. La seconde est la prise en charge de la traduction d'adresse machine physique -> machine virtuelle et inversement sur les processeurs ARM 32 et 64 bits. Cela permet aux machines virtuelles de programmer des transferts DMA depuis des périphériques réels sur les systèmes sans IOMMU.

Pour plus d'informations, vous pouvez consulter le pull request de Xen.

 

Source : http://linuxfr.org/news/sortie-de-linux-3-13