Sortie du noyau Linux 4.9

La sortie de la version stable 4.9 du noyau Linux a été annoncée le dimanche 11 décembre 2016 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

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).

Sommaire

• Annonces des versions candidates par Linus Torvalds
  • RC-1
  • RC-2
  • RC-3
  • RC-4
  • RC-5
  • RC-6
  • RC-7
  • RC-8
  • Version finale
• Sécurité
  • Pas de changement majeur du côté de la génération des nombres pseudo‐aléatoires
    • Réservoir d’entropie
    • Les fichiers /dev/urandom et /dev/random
    • Améliorations
    • Refus
  • Allouer les piles d’exécution du noyau en mémoire virtuelle
    • Problème de conception
      • 1. Fragmentation
      • 2. Petite taille
      • 3. Dépassement
      • 4. Contournements contre‐performants
    • Mémoire virtuelle
    • Trop lent
    • Mémoire tampon
    • Incompatibilité avec le Read‐Copy‐Update
    • Contournement du Read-Copy-Update
    • Interdépendance entre la mémoire de la pile et le Read‐Copy‐Update
    • Se débarrasser du thread_info
    • C’est gagné !
      • 1. Gain en performance
      • 2. Détection immédiate du dépassement de la pile d’exécution
      • 3. Meilleur diagnostic
    • Plébiscite
  • Clefs de protection de la mémoire (memory protection keys)
    • API
    • Voir aussi
• Pilotes graphiques libres
  • AMD
  • Nouveau
• Réseau
  • BBR
• Systèmes de fichiers
  • FUSE
  • UBIFS
  • ext4
  • Btrfs
  • F2FS
  • XFS
• Prise en charge des plates‐formes
  • Raspberry Pi Zero
  • Amlogic S905
  • Autres
• Autres nouveautés
  • Pilote de test EFI
  • Plate‐forme Mellanox
  • MD RAID
  • NVDIMM
  • Intel Integrated Sensor Hub (ISH)
  • Intel Atom
  • Projet ARA de Google
    • Unipro ?
    •  Greybus ?
  • Commande perf
  • KThread
  • Clef de protection mémoire
  • Virtualisation Xen et KVM
  • Virtual mapped stack
• Statistiques
  • Entreprises ayant participé à cette version
    • En nombre de lignes changées

Annonces des versions candidates par Linus Torvalds

RC-1

La version RC-1 est sortie le samedi 15 octobre 2016 :

Habituellement, je fais mes publications le dimanche après‐midi, mais de temps en temps, je raccourcis la fenêtre d’intégration d’un jour, pour garder les gens en alerte et m’assurer qu’ils ne se mettent pas à envoyer leurs demandes d’intégration [N. D. T. : pull requests] à la dernière minute. Ce n’est pas le dernier jour qu’on s’amuse à jouer avec la fenêtre d’intégration. Idem pour celle‐ci.

Pour être honnête, la raison qui m’a poussé à la sortir un jour plus tôt pour cette fois‐ci est moins d’empêcher les gens de jouer contre la montre avec leurs contributions, mais bien plus parce que cette fenêtre d’intégration était plutôt imposante et pas particulièrement réjouissante. J’ai dû arrêter la fusion par deux fois pendant cette fenêtre d’intégration, uniquement parce que je traquais divers problèmes. C’est ce qui a tendance à faire passer ma période d’activité sur la fenêtre de fusion du mode « occupé » à « légèrement stressant ».

Mais, bon, tout va bien maintenant. Et, même si la 4.9 semble être une grosse version et que nous avons eu quelques couacs, dans l’ensemble, les choses semblent normales. La grande nouveauté est l’ajout de Greybus, dont Greg jure qu’il est vraiment utilisé. Mais, sous le capot, le plus gros des modifications est, en réalité, tout un tas de petits détails, comme d’habitude.

Dans les « petits détails de dessous le capot », il se trouve que mon préféré concerne les nouvelles allocations de piles virtuelles du noyau par Andy Lutomirski. Elles simplifient la découverte et la récupération des débordements de la pile. L’effort a également permis de nettoyer du code et d’ajouter un cache de correspondance à la pile du noyau pour éviter des baisses de performance. Al a aussi travaillé sur quelques nettoyages de VFS et uaccess que j’ai suivis (en particulier un truc puant dans un modèle de liaison). Mais soyons réalistes : ce que je considère comme des petits détails sympas sont juste mes propres marottes, il y en a un peu partout.

Il se fait que le système de pile virtuelle signifie aussi qu’il est grand temps pour ceux qui ont la sale manie de faire des accès directs en mémoire (DMA) à l’aide de variables temporaires allouées sur la pile (« Ne faites pas ça ! ») de changer leurs habitudes. Cela aura des retombées et je m’attends à ce qu’il y ait quelques pilotes à corriger çà et là. Mais tout ceci est pour une bonne cause, vraiment (et ce n’est pas un usage très répandu, parce que faire un accès direct à la mémoire depuis la pile n’a jamais été une bonne idée et, de manière générale, même pas envisageable dans la plupart des situations).

Mais il y a vraiment beaucoup d’autres choses en cours et le sommaire des modifications, tel que je le fais pour les autres versions, est bien trop long pour la RC-1. Donc, comme d’habitude, j’adjoins mon « journal de fusion » à la place, ce qui donne une vue de très haut niveau de ce que j’ai fusionné et de qui cela provient. Et, comme d’habitude, je tiens à souligner que les personnes dont proviennent les contributions que je fusionne ne sont pas nécessairement celles qui ont fait le travail : nous avons eu 1 500 personnes impliquées dans cette version, seuls les mainteneurs de haut niveau sont cités dans mon journal de fusion.

Allez‐y et testez,

Linus

RC-2

La version RC-2 est sortie le dimanche 23 octobre 2016 :

Je suis de retour sur mon agenda de publication habituel le dimanche après‐midi et Linux 4.9-rc2 est disponible.

Ma nouvelle fonctionnalité préférée, telle que je l’avais nommée dans l’annonce de la RC-1 (les piles virtuelles) est peut‐être impliquée dans des plantages que Dave Jones a essayé de comprendre. Donc, si vous voulez vous rendre utile et voir si vous pouvez fournir plus de données, s’il vous plaît, assurez‐vous d’avoir activé la variable CONFIG_VMAP_STACK.

… d’un autre côté, si tout ce que vous voulez est d’éviter les tracas engendrés par ce problème particulier, désactivez les piles virtuelles pour l’instant ; mais, s’il vous plaît, aidez‐nous à tester.

Parce que la 4.9 est clairement en phase d’être une grosse version (je n’ai pas encore fait de véritables statistiques, mais je pense que c’est la plus importante version que nous ayons jamais eue en nombre de modifications enregistrées [N. D. T. : commits]) et je pense que Greg prévoit aussi d’en faire une version LTS. Il se peut que les deux soient liés, avec tous ceux qui insistent pour que leurs trucs soient prêts. Bref, plus il y en a qui testent, plus tôt ils commencent à tester dans la série des RC, plus tôt nous en aurons fini. Un indice ! Un indice !

OK, sujet clos. La RC-2 elle‐même n’est pas énorme, mais c’est un cas fréquent : soit les gens prennent une pause après la fenêtre de fusion, soit c’est juste qu’il leur faut un moment avant de découvrir les retombées du nouveau code source ; donc, comme d’habitude, la RC-2 est dans le lot des petites versions.

En revanche, nous avons des modifications un peu partout : les pilotes dominent (les pilotes graphiques sortent du lot, mais il y a [aussi] IPMI, clocksource, MMC, pinctrl, HID, SCSI, NVMe… En veux‐tu, en voilà). Ajoutez à cela quelques mises à jour d’architectures (x86 et ARM64), un peu de nettoyage sur les systèmes de fichiers (ext4, NFS, Ceph, F2FS), les machines virtuelles, plus un gros correctif et vous en avez à peu près fait le tour.

Le sommaire des modifications ci‐joint donne quelques détails et, pour encore plus de détails, vous pouvez toujours parcourir l’arborescence Git en question.

Linus

RC-3

La version RC-3 est sortie le samedi 29 octobre 2016 :

Je publie la RC-3 un samedi, non pas pour attraper tous ceux qui s’amuseraient à m’envoyer des trucs à la dernière minute, mais simplement parce que, demain, je pars en voyage pour le Kernel Summit.

Il s’avère que le bogue que nous pensions dû aux nouvelles piles virtuelles pendant les tests de la RC-2 n’avait rien à voir avec ça ; il s’agit d’un problème d'accès concurrents à la file d’attente des requêtes de blocs. Donc, ceux qui avaient désactivé la nouvelle fonctionnalité n’y échappaient pas du tout, alors que les personnes touchées étaient probablement, tout comme DaveJ, ceux qui effectuent des tests de montée en charge. Mais tout ça est corrigé maintenant et nous devrions être parés.

Il y a également un tas d’autres corrections un peu partout. Les statistiques des modifications ont l’air un peu bizarres, avec les corrections sur XFS qui prennent quasiment autant de place que celles portant sur les pilotes ; mais ce sont principalement des corrections du nouveau code de reflink incorporé durant cette version. De toute façon, vous ne devriez pas avoir été touché, à moins que vous n’utilisiez les derniers trucs à la mode.

À part ça ? Tous les divers correctifs habituels de pilotes, mises à jour d’architectures, etc. Le sommaire des modifications ci‐joint n’est vraiment pas petit (comme on pouvait s’y attendre, la RC-3 était plus grosse que la RC-2), mais il est assez facile à parcourir pour avoir ne fût‐ce qu’une idée de ce qui s’est passé.

Donc, allez‐y, testez.

Linus

RC-4

La version RC-4 est sortie le samedi 5 novembre 2016 :

C’est de nouveau un samedi après‐midi plutôt qu’un dimanche. Cette fois, c’est parce que je sentais que cette RC était déjà suffisamment grosse.

Une part de cette taille vient probablement du seul fait que la 4.9 est énorme, avec quelques changements en profondeur : nous avons un certain nombre d’améliorations apportées aux pilotes et systèmes de fichiers qui ont provoqué une avalanche de problèmes du genre « la pile est actuellement virtuellement mise en correspondance et les adresses physiques ne fonctionnent pas ».

Mais une plus grande part est tout simplement due aux premières corrections réseaux venant juste d’arriver après la RC-3, ce qui représente une large portion de celle‐ci (environ un tiers en vrac, légèrement plus en nombre de modifications enregistrées [N. D. T. : commits] — réparti à la fois sur les pilotes et l’architecture réseau).

Je ne vais pas mentir : ce n’est pas une petite RC, et j’aurais été plus heureux si elle l’avait été. Mais ce n’est pas déraisonnablement grand pour cette (grosse) version, donc ce n’est pas comme si je devais m’en inquiéter. J’envisage toujours de sortir cette version au bout de sept [versions] candidates, pour autant que les choses commencent à se calmer. Nous verrons ce que ça donne à mesure que nous nous rapprocherons de la date de sortie.

Quoi qu’il en soit, environ la moitié des changements sont imputés aux pilotes (le réseau en étant une partie non négligeable, mais aussi les pilotes média, graphiques et autre bric‐à‐brac). Environ un tiers sont des mises à jour d’architecture (SPARC et MIPS se démarquent, mais il y a aussi x86 et PA-RISC, plus quelques petites mises à jour sur ARM). Pour le reste, on a essentiellement l’architecture réseau et une poignée d’autres changements (systèmes de fichiers, tests). Et Arnd est toujours en train d’éliminer ses erreurs de variables non initialisées, de sorte que nous espérons pouvoir réactiver cet avertissement pour la 4.9 finale. On verra bien.

Le sommaire des modifications ci‐joint n’est pas petit, mais vous pouvez, genre, le parcourir et avoir un aperçu de ce qui s’est passé la semaine dernière.

Linus

RC-5

La version RC-5 est sortie le samedi 13 novembre 2016 :

De retour à mon agenda du dimanche, tout a l’air plutôt normal. Calme au début, avec la plupart des corrections qui tombent en fin de semaine. J’ai l’habitude, maintenant.

Aucun doute là-dessus, tout a franchement diminué et, malgré l’embonpoint de la 4.9, un agenda de sortie habituel semble encore possible (avec la rc7 en dernier). Mais voyons comment les choses évoluent au cours des prochaines semaines. En attendant, il y a beaucoup de corrections ordinaires ici et il nous faut encore plus de tests.

Les statistiques de cette RC-5 sont franchement barbantes (ce qui est une bonne chose). Deux tiers de mises à jour des pilotes, 10 % de mises à jour d’architectures, 10 % sur les systèmes de fichiers, le reste en « divers ». Rien de frappant, sauf peut‐être à la prochaine réactivation [N. D. T. : l’option de compilation] de -Wmaybe-uninitialized dès que Arnd aura tout corrigé.

Donc, allez‐y, testez.

Linus

RC-6

La version RC-6 est sortie le dimanche 20 novembre 2016 :

On avance dans la série des RC et, même si tout a été plutôt calme, je ne suis pas certain qu’on soit près du but. Il reste encore à corriger quelques problèmes qui n’ont rien à faire dans une RC-6, alors on va garder un œil là‐dessus. Il se pourrait qu’on ait une de ces sorties incluant une RC-8, ce qui, compte tenu de la taille de la 4.9, n’est peut‐être pas si inhabituel que ça.

Cela dit, il n’y a rien de particulier qui ne me dérange vraiment. En revanche, nous avons des corrections de VMALLOC_STACK qui continuent d’arriver au compte‐gouttes et j’ai peur qu’on ne soit pas encore près d’en voir la fin. Aussi, attendons de voir à quoi la liste des régressions de Thorsten ressemblera la semaine prochaine. Donc, je n’ai pris encore aucune décision, d’un côté ou de l’autre, ça ira quand‐même.

Que la RC-6 soit plus grosse que la RC-5 n’est pas particulièrement bon signe, en revanche. Mais, apparemment, tout ceci n’est que le reflet des fluctuations habituelles sur le rythme des sorties : la RC-6 avait des mises à jour réseau, mais pas la RC-5, par exemple. Il y a aussi quelques mises à jour de RDMA qui se démarquent. Rien de bien inquiétant.

À part le réseau susmentionné et le RDMA, il y a des corrections au niveau des pilotes graphiques, un peu de corrections sur les outils et l’assemblage, plusieurs mises à jour sur les architectures (x86, PowerPC, ARM et Xtensa). Plus quelques corrections un peu partout (I²C, son, FUSE, KVM…).

Allez‐y, testez.

Linus

RC-7

La version RC-7 est sortie le dimanche 27 novembre 2016 :

Toujours dans le cadre de l’agenda des sorties dominicales, voici la RC-7.

Je pense que nous avons fait corriger tous les bêtes problèmes dont j’avais connaissance et, dans l’ensemble, les choses ont l’air d’aller plutôt bien. En fait, si la semaine prochaine se termine bien tranquillement, il se pourrait que cela soit la dernière RC, même si, honnêtement, je soupçonne fortement d’avoir à finir par une RC-8. C’est une grosse version et la RC-7 aurait pu être plus calme. On verra.

Je me réserve le droit de me décider le week‐end prochain.

Dans la RC-7, ce sont principalement les pilotes, l’architecture et le réseau qui ont été modifiés. En réalité, la plupart des mises à jour de pilotes concernent le réseau, je crois donc pouvoir dire « surtout des mises à jour de pilotes réseau et d’architectures, avec une poignée de mises à jour d’autres pilotes » (dans ces autres catégories de pilotes, on a notamment USB, pilotes graphiques, HID, I²C et IOMMU). Et l’on a toujours les trucs habituels un peu partout (le noyau, une correction eBPF, quelques corrections sur les systèmes de fichiers, etc.).

Le sommaire des modifications ci‐joint donne une assez bonne vue sur ce qui a été fait.

Linus

RC-8

La version RC-8 est sortie le dimanche 4 décembre 2016 :

Alors, pour ceux qui auront suivi l’arborescence Git, ça ne devrait pas être une surprise si j’ai fini par faire une RC-8, en définitive : non pas que les choses aient mal tourné, mais ça n’a pas non plus été le calme plat qui m’aurait fait dire « pas de quoi se taper encore une semaine ».

Et les félicitations du jury pour Arnd, qui a fini par trouver la véritable cause de ces messages incroyablement pénibles « modversions ne fonctionnent pas avec les nouvelles versions de binutils », en décortiquant les traces jusqu’à une modification bien précise dans la manière dont binutils gère les symboles, puis en ajoutant un petit correctif d’une ligne au noyau pour contourner le problème. Nous avions déjà d’autres solutions en place, mais il est toujours bon de savoir exactement ce qui a changé dans la chaîne d’outils pour provoquer ce genre de chose.

Cependant, cette ligne unique n’était qu’une des 163 petites corrections (sans compter les fusions) apportées à la RC-8. C’est assez petit (pour le noyau), mais pas complètement insignifiant. Tous les détails sur les modifications figurent au sommaire des modifications, mais c’est en majorité dans les pilotes réseau (des fuites dans la gestion des retours d’erreurs subsistent, mais la liste est disparate) et autres par‐ci, par‐là, avec en plus de petites corrections de trucs liés au noyau (mémoire virtuelle, systèmes de fichiers et noyau).

Linus

Version finale

La version finale est sortie le dimanche 11 décembre 2016 :

Ainsi, Linux 4.9 est sorti et, par conséquent, la fenêtre de fusion pour la 4.10 est ouverte.

Avec la semaine supplémentaire prise par la 4.9, le calendrier de la période de fusion est évidemment un peu gênant et devrait techniquement se clôturer dans deux semaines, autrement dit le jour de Noël. Mais c’est une pure question de technique, parce que je vais certainement arrêter l’intégration le 23 au plus tard ; et, si je suis enrôlé dans les préparatifs du repas de Noël, même cette date pourrait être remise en question.

Je pourrais étendre la fenêtre de fusion plutôt que de la raccourcir, mais je ne vais pas le faire. Je suppute que nous voulons tous une gentille pause d’hiver en paix ; donc, si vos affaires ne sont pas prêtes pour la fusion suffisamment tôt, la solution est bel et bien de ne pas les fusionner du tout et d’attendre la 4.11. Ceci pour que vous soyez tous au parfum (j’ai déjà averti la semaine dernière en message privé ceux que je suspecte de vouloir utiliser la fenêtre de fusion principale ; je me répète ici afin d’éviter la confusion à propos de l’agenda).

Quoi qu’il en soit, revenons à la 4.9.

Je suis sûr que c’est la plus grosse sortie que nous ayons jamais eue, au moins dans le nombre de modifications inscrites [N. D. T. : commits]. Si vous jetez un œil au nombre de lignes modifiées, nous avons eu des versions plus importantes dans le passé, mais elles avaient tendance à être dues à des problèmes spécifiques (par exemple, la version 4.2 a pris pas mal de lignes dans les fichiers de définition des registres des processeurs graphiques d’AMD et il y a eu de grosses restructurations ayant engendré un grand nombre de lignes par le passé : la version 3.2 était de grande taille en raison de la zone d’attente [N. D. T. : staging], la version 3.7 avait la désintégration automatisée du fichier d’en‐tête uAPI, etc.). À côté, la 4.9 est juste énorme.

Certes, la nouvelle prise en charge de Greybus est un bon morceau, mais ce n’est vraiment pas le plus gros — c’est juste un autre petit détail dans l’ensemble « oui, la version 4.9 est une version importante ».

En dehors de sa taille, la 4.9 semble plutôt normale. Un peu plus de deux tiers des pilotes (en gros la branche staging, les pilotes graphiques et réseau, mais il y en a partout), le reste aussi est plutôt normal : mises à jour d’architectures, documentation, infrastructure réseau générale, systèmes de fichiers…

Le sommaire (plus de 16 000 modifications inscrites, ainsi qu’un autre lot de 1 100 fusions, pour arrondir le tout) est évidemment beaucoup trop volumineux pour être écrit ici ; ce serait illisible de toute façon. Donc, comme à mon habitude, j’ajouterai seulement le journal de mes fusions.

Linus

Sécurité

Pas de changement majeur du côté de la génération des nombres pseudo‐aléatoires

Contrairement à ce que laisse penser Phoronix, les contributions de Stephan Müller concernant son « Linux Random Number Generator » (LRNG) n’ont toujours pas été intégrées au noyau. Les rédacteurs de vos dépêches favorites vérifient scrupuleusement l’historique des changements et ne se font pas avoir.

Profitons‐en quand même pour présenter cette partie du noyau. :-)

Réservoir d’entropie

Afin d’obtenir le plus d’aléa (le plus d’entropie), le noyau collecte toutes les sources de bruit à sa disposition, généralement les variations infimes (le bit de poids faible) de différentes mesures. Voici quelques exemples : température (processeur, disque dur), heure d’arrivée des paquets réseau, défaut de cache (cache miss), temps d’accès à la mémoire, ticks. Le noyau a aussi à sa disposition des instructions spéciales du processeur. En revanche, ces instructions ne sont pas auditables (par un organisme indépendant) car les conception et fabrication des processeurs sont rarement accessibles. Et le noyau prend surtout en compte les sources d’entropie de confiance.

Les fichiers /dev/urandom et /dev/random

La lecture du fichier /dev/urandom génère un nombre pseudo‐aléatoire (uniform random) à partir du réservoir d’entropie. La lecture du fichier /dev/random génère aussi un nombre pseudo‐aléatoire, mais sa lecture reste bloquée tant que le noyau n’a pas collecté suffisamment de bruit. Un démon s’initialisant au démarrage du noyau va plutôt opter pour /dev/urandom pour éviter de se bloquer. Une application ayant besoin d’une garantie d’entropie sur un nombre aléatoire utilisera plutôt /dev/random. La fonction getrandom() (en langage C) propose exactement ces mêmes services.

Améliorations

Stephan Müller avait proposé de rajouter 1 800 lignes de code source C pour changer la collecte d’entropie, dont les détails de conception et ses tests sont disponibles en HTML et en PDF. Ses principaux objectifs sont :

• exploiter les SSD dans cette collecte d’entropie (on ne peut pas exploiter le réseau, car il n’est pas encore disponible) ;
• exploiter les fonctions matérielles de génération pseudo-aléatoire ;
• limiter par défaut les sources non auditables à un trente-deuxième du réservoir d’entropie ;
• augmenter davantage l’entropie dès le démarrage et permettre la lecture du fichier /dev/random le plus tôt possible ;
• améliorer l’entropie même dans une machine virtuelle ;
• améliorer la performance sur les systèmes massivement multi‐cœurs et évitant les collectes d’entropie inutiles ;
• permettre de tester de façon déterministe chacune des étapes ;
• proposer une option (switch) de construction du noyau CONFIG_CRYPTO_LRNG pour choisir entre l’ancien et le nouveau fonctionnement (important pour les environnements avec peu de mémoire).

Refus

Ce sont surtout les agences nationales de sécurité informatique, comme l’ANSSI française, le BSI allemand ou le NIST aux États‐Unis, qui sont intéressées par de telles améliorations. Mais elles n’apprécient pas les changements non audités…

Allouer les piles d’exécution du noyau en mémoire virtuelle

Les contributions (correctifs) d’Andy Lutomirski concernant les fils d’exécution (threads) du noyau sont certainement celles que Linus a le plus appréciées, d’après son message de la RC-1. Il faut dire qu’Andy vient de loin et a travaillé avec acharnement pour trouver des solutions radicales à tous les problèmes rencontrés et, au final, a joliment nettoyé les tréfonds du code source du noyau.

Ce chapitre retrace cette aventure tumultueuse et se base sur les excellents articles de LWN.net rédigés par Jonathan Corbet (juin 2016) et sous licence CC BY-SA 4.0 :

• Virtually mapped kernel stacks
• Virtually mapped stacks 2: thread_info strikes back

Problème de conception

Andy s’est attaqué au vieux problème de conception du noyau Linux des piles d’exécution (call stacks). Ces piles étaient toujours allouées directement en mémoire physique, avec des inconvénients ennuyeux.

1. Fragmentation

Toute la pile doit tenir en un seul bloc de mémoire physique contigüe. Mais les grands blocs contigus sont de plus en plus difficiles à trouver au fur à mesure de la fragmentation de la mémoire. Ce qui met en péril un noyau Linux qui réalise de nombreuses opérations critiques depuis longtemps, surtout quand une attaque titille le noyau en le forçant à fragmenter sa mémoire.

2. Petite taille

Pour réduire les risques de fragmentation, la taille des piles d’exécution est limitée généralement à 8 192 petits octets. Ce qui impose des contraintes strictes comme l’interdiction des appels récursifs, pas de structure passée par valeur et l’obligation d’analyser en détail les possibles enchaînements des appels de fonctions. Et de nombreuses personnes préféraient plutôt en avoir une plus grosse !
Même si parler de code récursif dans un noyau, cela fait froid dans le dos, car cela veut dire un risque de « stack overflow » selon la taille des données traitées (et c’est mal) !

3. Dépassement

Malgré toute l’attention sur les arbres d’appel, les dépassements de pile (stack overflow) sont possibles. Une attaque peut trouver des combinaisons pour provoquer un dépassement et écraser des informations et même introduire son code exécutable. D’ailleurs, la taille a dû être doublée à 16 Kio sur les architectures x64.

4. Contournements contre‐performants

Pour détecter un dépassement, une solution consiste à positionner un canari à l’extrémité de la pile d’exécution. Ce canari correspond à une valeur magique qui est vérifiée régulièrement afin de détecter son écrasement par une autre valeur et donc un dépassement de la pile d’exécution. Non seulement, cela oblige à réaliser des opérations supplémentaires (vérifier plus ou moins fréquemment), mais en plus, ce dépassement n’est détecté qu’a posteriori et c’est souvent trop tard.

Une seconde solution pour détecter un dépassement en mémoire physique consiste à rajouter une page mémoire en accès interdit. Mais cela gâche de la mémoire qui n’est pas utilisée et augmente le risque de fragmentation (le bloc de mémoire contigu doit être plus grand).

Et que faire si le dépassement est détecté ? Tuer le fil d’exécution ou ré‐allouer une pile plus grande ? Avec la mémoire physique, tuer est plus facile que ré‐allouer. De plus, il faut utiliser une fonction realloc() différente, car la pile s’exécute de la fin vers le début, donc il faut ajouter de la mémoire avant et non après. Sans parler des risques d’augmentation de la fragmentation.

Mémoire virtuelle

L’idée initiale d’Andy était de proposer un agrandissement automatique de la taille de la pile d’exécution au fur et à mesure que son dépassement est détecté en allouant cette pile en mémoire virtuelle. La gestion de la mémoire virtuelle a été un des tous premiers objectifs du noyau Linux avec le processeur i386. C’est le MMU du processeur qui donne l’impression au fil d’exécution que la plage d’adresses est contigüe, mais les pages de la mémoire physique (des blocs généralement de 4 Kio) peuvent être dispersées, réduisant considérablement les problèmes de fragmentation.

Pour atteindre ce but ultime, Andy a remanié ses contributions à de très nombreuses reprises et son acharnement a abouti à des résultats spectaculaires non attendus.

Trop lent

Au tout début, le seul inconvénient de sa première proposition était une lenteur de 1,5 µs lors de la création d’un nouveau fil d'exécution du noyau. Ce temps d’exécution plus long est imputable à la fonction vmalloc() utilisée pour allouer de la mémoire à la pile d’exécution (virtual memory allocation — allocation de mémoire virtuelle). Cette fonction prend plus de temps, car elle réalise des opérations supplémentaires et n’a pas bénéficié du même effort d’optimisation que les autres fonctions d’allocation. Mais, pour Linus, cette régression de performance est irrecevable.

Mémoire tampon

Alors, voyons comment éviter d’appeler la fonction vmalloc(). Pour cela, Linus a demandé à Andy de recycler les piles d’exécution des derniers fils s’étant terminés. On les conserve temporairement dans une petite mémoire tampon et on les fournit dès qu’il faut créer un nouveau fil d’exécution. Cela devrait nous permettre d’appeler vmalloc() moins souvent.

Incompatibilité avec le Read‐Copy‐Update

Mais, c’est oublier le fonctionnement fourbe du Read‐Copy‐Update (RCU) qui libère les ressources d’un fil d’exécution (dont sa pile d’exécution) par saccade. Le RCU accumule les ressources de tous les fils d’exécution qui se terminent, puis les libère tous en même temps. Notre petit cache de piles d’exécution se retrouve donc à devoir absorber plus de piles d’exécution qu’il ne peut en contenir. Et, en attendant le prochain cycle du RCU, nous nous retrouvons rapidement avec un cache vide et donc la nécessité d’appeler la fonction vmalloc().

Contournement du Read-Copy-Update

Au lieu d’augmenter la capacité de notre cache (pensons aux systèmes avec peu de mémoire), essayons de décorréler la pile d’exécution du mécanisme RCU. En récupérant nous‐même la pile d’exécution d’un fil qui se termine, nous évitons les pics de piles d’exécution fournis par le RCU. En revanche, le RCU libère les autres ressources du fil d’exécution à son rythme.

Interdépendance entre la mémoire de la pile et le Read‐Copy‐Update

Mais, nous avons un autre problème : la pile d’exécution et les autres ressources du fil d’exécution ne sont pas complètement décorrélées. En fait, les informations du fil d’exécution sont dispersées à deux endroits :

1. dans la structure task_struct, qui est allouée indépendamment de la pile d’exécution (ouf) ;
2. dans la structure thread_info, qui fait partie du même bloc mémoire que la pile d’exécution (zut).

C’est là que les choses se compliquent : les différentes parties du noyau ne vont pas immédiatement être au courant qu’un fil d’exécution vient de se terminer, cela prend un certain temps pendant lequel la structure thread_info ne peut être utilisée par un nouveau fil d’exécution. On en revient au même : attendre la fin du cycle du RCU !

Se débarrasser du thread_info

Et si nous déplacions le thread_info ailleurs ? Eh bien, c’était comme cela au début du noyau, tout était dans task_struct. Mais avoir quelques informations directement dans le même bloc mémoire que la pile d’exécution permet justement d’éviter une indirection. D’ailleurs, c’est l’essence même de l’existence de task_struct : permettre un accès direct en appliquant un masque sur le pointeur d’exécution ($sp).

Avec le temps, la structure task_struct contient les champs génériques, indépendants de la plate‐forme (architecture‐independent). Et la structure thread_info contient les champs spécifiques à la plate‐forme (architecture‐specific).

Pourtant, ces dernières années, la structure thread_info a fondu. Quelques champs de cette structure ont été déplacés dans une structure de données spécifique à chaque cœur (unité de calcul). Mais, ce n’est pas là non plus que nous pouvons déplacer des champs de thread_info, car seul le code s’exécutant sur ce cœur a le droit d’accéder à sa structure de données spécifique, afin d’éviter que le processeur perde du temps à synchroniser les caches mémoire de niveau 2.

C’est là que Linus a donné un coup de main à Andy. D’abord, en réduisant la dépendance entre les différentes parties du noyau vis‐à‐vis de la structure thread_info. Puis, en déplaçant certains champs vers task_struct. Andy a poursuivi ce travail pour chaque champ. Et le dernier champ contenant les drapeaux (flags) a également été déplacé vers task_struct. Mais cela demande tellement d’investissement sur chaque plate‐forme spécifique, qu’Andy a mené à bien ce travail uniquement pour la plate‐forme x86.

C’est gagné !

Maintenant, nous avons enfin la mémoire de la pile d’exécution qui peut être directement libérée dès la fin du fil d’exécution, sans avoir besoin d’attendre la fin du cycle RCU. Et nous pouvons donc mettre en cache cette pile d’exécution dans la structure de données spécifique à chaque cœur.

Les avantages de la contribution d’Andy sont nombreux :

1. Gain en performance

En faisant des tests avec un petit cache pour deux piles d’appel, la latence de 1,5 µs se transforme en un gain de performance entre ½ et 1 µs.

2. Détection immédiate du dépassement de la pile d’exécution

En plus de ce gain de performance, nous avons aussi un dépassement de la pile (stack overflow) qui est immédiatement détecté. Avant, le dépassement de la pile commençait par écraser la structure thread_info, ce qui ne pouvait pas être détecté (car cela ne dépassait pas le bloc mémoire). D’ailleurs, c’était une faille de sécurité importante. En faisant exécuter par le noyau un long enchaînement de fonctions, on pouvait changer les valeurs dans thread_info.

3. Meilleur diagnostic

Et, comme en cas de dépassement de pile, les informations de thread_info ne sont plus écrasées, il est plus facile de diagnostiquer le problème et ce, sans planter le noyau. Le dépassement est détecté, le noyau arrête le fil d’exécution et fournit un rapport d’erreur complet et précis.

Plébiscite

Devant l’avalanche de tels avantages, dont le nettoyage/regroupement des informations des fils d’exécution, les autres architectures sont en train d’être adaptées afin de ne plus avoir le thread_info dans le même bloc mémoire que la pile d’exécution.

En conclusion, cette épopée dans les entrailles du code source du noyau a permis de belles réalisations et Andy va pouvoir reprendre son idée initiale d’agrandir automatiquement la taille de la pile d’exécution en détectant son dépassement mémoire. Le noyau pourrait avoir à l’avenir des petites piles d’exécution pour la grande majorité des cas. Et pour une minorité de cas, la taille de la pile s’adaptera dynamiquement sans avoir à tuer le fil d’exécution. C’est un très bon compromis entre économie de mémoire et sécurité accrue.

Merci Andy Lutomirski et bonne continuation dans ton formidable travail.

Clefs de protection de la mémoire (memory protection keys)

Cette nouvelle fonctionnalité abrégée pkeys permet d’empêcher que d’autres processus accèdent à des plages d’adresses. C’est le rêve des cryptographes : cacher ses secrets.

Cette technologie existait déjà sur les bons vieux ordinateurs centraux — mainframes — (Key‐controlled memory protection). Et voilà qu’Intel l’intègre depuis le Skylake pour serveur (commercialisé depuis un an).

Dave Hansen (Intel) avait proposé une prise en charge, mais elle a été refusée pour la version 4.6. Puis améliorée, mais encore refusée pour la 4.7. Et, rebelote pour la 4.8. La contribution de Dave Hansen a enfin été acceptée pour la 4.9, au bout de la sixième révision.

API

Nous avons maintenant ces nouvelles fonctions dans l’API du noyau :

int pkey_alloc(unsigned long flags, unsigned long init_access_rights)
int pkey_free(int pkey);
int pkey_mprotect(unsigned long start, size_t len, unsigned long prot, int pkey);

Dans les précédentes révisions de cette contribution, il y avait deux autres fonctions. Nous les signalons pour éviter que nos lecteurs se trompent en se basant sur des documentations obsolètes. Dave Hansen a récemment nettoyé leurs traces du noyau :

/* Fonctions supprimées */
unsigned long pkey_get(int pkey);
int pkey_set(int pkey, unsigned long access_rights);

Ces nouvelles fonctions permettent donc de protéger en écriture seulement ou en lecture et écriture des adresses mémoire. Attention, l’implémentation sous‐jacente d’Intel peut être contournée, car les nouvelles instructions ajoutées, RDPKRU et WRPKRU, peuvent être utilisées par d’autres fils d’exécution.

Voir aussi

Toutes ces documentations sont en langue anglaise. Si les lectrices et lecteurs de LinuxFr.org souhaitent lire une dépêche en français sur ce sujet, merci de nous le signaler dans les commentaires.

Les excellents articles de Jonathan Corbet (CC BY-SA 4.0) publiés sur LWN.net :

• Memory protection keys v5 (décembre 2015) ;
• Memory protection keys (mai 2015) ;
• System calls for memory protection keys (juin 2016) ;
• Memory protection keys pushback (juillet 2016) ;
• Documentation/x86/protection-keys.txt (octobre 2016).

Manuel de l’API Linux :

• Overview of Memory Protection Keys ;
• pkey_alloc() et pkey_free() ;
• mprotect() et pkey_mprotect().

Couches bas niveau :

• fonctionnalités de sécurité du processeur Intel ;
• manuel du développeur des architectures Intel 64 et IA-32 (vol. 3A) (lire §4.6.2).

Pilotes graphiques libres

AMD

Le nouveau pilote graphique libre amdgpu pour les cartes graphiques AMD GCN a été mis à jour et introduit la prise en charge de l’affichage virtuel. Son contenu est ensuite accessible via un logiciel de bureau à distance.

Autre changement apporté par ce pilote, la prise en charge de la technologie de réduction de consommation énergétique AMD PowerPlay pour les cartes graphiques équipées d’un processeur graphique de génération Iceland (2014).

L’amélioration de la réinitialisation des unités de calcul accéléré (APU) de génération Carrizo (2015), ainsi que de son remplaçant Stoney Ridge (2016).

La prise en charge des circuits intégrés spécialisés (ASIC) AMD UVD (Unified Video Decoder), permettant le décodage vidéo, et AMD VCE (Video Coding Engine), qui permet le codage des normes vidéo de type H.264, MPEG-2, MPEG-4 et VC-1, a été ajoutée pour les puces plus récentes.

Prise en charge également de la pré‐initialisation de la mémoire tampon de la VRAM, par exemple, la remise à zéro.

Et de nombreuses autres corrections de bogues en tout genre.

Voir aussi :

• [Phoronix] The Exciting Features Of The Linux 4.9 Kernel ;
• [Phoronix] AMDGPU Patches For Virtual Display Feature ;
• [pull] radeon and amdgpu drm-next-4.9.

Nouveau

Aucun changement pour le pilote nouveau n’a été intégré à cette version du noyau.

Réseau

BBR

Le protocole TCP est l’un des plus utilisés sur Internet. Il est, entre autres, utilisé par HTTP et SSH. L’un des atouts de ce protocole est sa capacité à gérer la congestion, c’est‐à‐dire, sa capacité à continuer de fonctionner quand le réseau commence à être saturé par les connexions. En effet, lorsque l’on augmente le trafic sur un réseau, le temps d’attente dû à des interblocages augmente (sur Ethernet, il n’y a qu’une seule trame à la fois, par exemple). TCP est capable de réduire son débit automatiquement pour réduire cette congestion.

Depuis la création de TCP, différents algorithmes ont vu le jour pour améliorer le débit, car les premières versions ne pouvaient pas atteindre les 100 Mbit/s, par exemple. Le BBR (pour Bottleneck Bandwidth and RTT) fait donc suite aux douze autres protocoles permettant à TCP de réduire son débit lorsque le réseau est congestionné tout en maximisant les débits (dans les cas sans congestion et lors de la congestion). Il faut comprendre que ces algorithmes ont différentes propriétés. D’une part, on cherche à ce qu’ils soient le plus efficace possible pour améliorer le débit utile par rapport à l’ensemble du débit consommé, ensuite, il y a différentes façons de se comporter lors de la congestion. Par exemple, le débit peut augmenter plus ou moins vite une fois la congestion passée. La meilleure solution dépendra (entre autres) des couches inférieures du réseau (comme le lien physique) et des autres équipements. C’est ce qui explique qu’il y ait encore tant d’algorithmes différents pour répondre à la même problématique.

Ce nouvel algorithme a été proposé par une équipe de Google. Ces derniers expliquent que BBR, contrairement aux autres algorithmes, ne se base pas sur des pertes de paquets, mais sur des mesures faites au fur et à mesure. Ainsi, il n’attend pas d’être dans les pires cas pour ajuster son débit. Ils expliquent aussi que cet algorithme est déjà utilisé dans les infrastructures de YouTube et de Google Search (excusez du peu). Un des premiers tests publics qui compare l’algorithme TCP Reno, TCP CUBIC et TCP BBR semble montrer de bons résultats.

• [LWN] BBR congestion control ;
• [Wikipédia] Algorithme TCP ;
• [CeroWrt notebook] A quick look at TCP BBR ;
• [ozlabs.org] [net-next,14/14] tcp_bbr: add BBR congestion control ;
• [Wikipédia] Congestion réseau ;
• [Wikipédia] Transmission Control Protocol ;
• [BBR Development] BBR Congestion Control Development ;
• [git.kernel.org] tcp_bbr: add BBR congestion control.

Systèmes de fichiers

FUSE

FUSE (pour Filesystem in Userspace) a été mis à jour. Il permet à un utilisateur sans privilèges particuliers d’accéder à un système de fichiers, sans qu’il soit nécessaire de modifier les sources du noyau. Il est utilisé dans GNOME (GVfs), pour écrire sur des partitions NTFS (NTFS-3G), par VeraCrypt, ou encore Flatpak.

Le correctif de FUSE apporte enfin la vérification des permissions (ACL) POSIX, ainsi que diverses corrections de bogues. Ceux qui souhaitent découvrir ce que sont les listes de contrôle d’accès POSIX sous Linux peuvent lire l’article (en anglais) qui leur est dédié. Lire aussi la version française sur Wikipédia de leur mise en œuvre sous UNIX.

UBIFS

Un correctif proposé par Bean Huo introduit la gestion d’OverlayFS. Pour ceux qui se servent d’UBIFS sur de la mémoire Flash brute, il n’existe pas, en ce moment, de prise en charge d’OverlayFS. Néanmoins le travail est en préparation pour les mémoires Flash de type MLC NAND (mémoires Flash NAND à cellules multi‐niveaux).

ext4

Corrections et nettoyages, notamment dans la gestion des attributs étendus.

Btrfs

Correction de bogues et diverses optimisations. Rien d’excitant pour le moment. Chris Mason signale d’ailleurs que des modifications plus importantes sont en préparation pour la version 4.10.

F2FS

F2FS, le système de fichiers de Samsung dédié à la mémoire Flash, a reçu plusieurs améliorations :

• l’option inline_dentry est désormais activée par défaut, ce qui devrait améliorer l’utilisation de l’espace disque et les performances pour les systèmes de fichiers avec beaucoup de petits répertoires ;
• F2FS peut maintenant préallouer des blocs pour les fichiers chiffrés. La commande trim a également reçu quelques améliorations.

XFS

XFS, le système de fichiers hérité d’IRIX, l’UNIX de SGI, s’est vu ajouter un nombre important de fonctionnalités, notamment à son infrastructure, mais aussi au format des données. Suite aux contributions soumises par Dave Chinner, un espace disque peut désormais avoir plusieurs propriétaires (XFS Shared Extents ou zones disque partagées), ceci grâce à l’adjonction, dans chaque groupe d’allocation, d’un nouvel arbre B (B‐tree) répondant au doux nom de refcount.

Prise en charge des plates‐formes

Raspberry Pi Zero

La gestion du Raspberry Pi Zero a été ajoutée en même temps que d’autres systèmes mono‐puces de Broadcom.

Amlogic S905

La prise en charge de l’Amlogic S905 a été améliorée. La gestion des systèmes mono‐puces ARM 64 bits d’Amlogic fait l’objet d’un gros travail depuis Linux 4.7. On a en plus grâce à Linux 4.9, notamment :

• PWM (modulation en largeur d’impulsions), pierre angulaire de la gestion du Wi‐Fi sur les cartes Amlogic ;
• la Mailbox, utilisée pour la communication SCPI qui gère le DVFS (adaptation dynamique de la tension d’alimentation et de la fréquence d’un micro‐processeur) ;
• l’I²C et le SPI ;
• des améliorations de l’Ethernet 10, 100 et 1000 Mbit/s.

La gestion de MMC/SD/SDIO, SCPI et de l’USB est malheureusement repoussée pour Linux 4.10. Cette dernière intégrera le Wi‐Fi (si les pilotes SDIO sont dans Linux) et les variantes S905D, S905X et S912.

Autres

On voit également débarquer la prise en charge de diverses plates‐formes et composants :

• ZTE ZX296718, SoC ARM 64-bit ;
• les systèmes mono‐puces Broadcom BCM47189 et BCM53573, premiers systèmes mono‐puces ARM à se conformer au standard Wi‐Fi 802.11ac. ;
• Renesas r8a7796 (R-Car M3-W), système mono‐puce pour l’automobile ;
• le NextThing GR8, très proche de celle du A13/R8 ;
• la platine de développement Marvell Armada 8040 avec son Cortex-A72 à quatre cœurs et ses trois interfaces Ethernet 10 Gbit ;
• la carte Qualcomm DragonBoard 820c 96Boards ;
• TVBox Tronsmart Orion r86, une carte pour boîtiers décodeurs avec un système mono‐puce octocœur Rockchip RK3368 ;
• Qualcomm External Bus Interface 2 (EBI2), utilisé sur les téléphones pour connecter la mémoire Flash, les écrans LCD et d’autres périphériques ;
• les cartes Allwinner, incluant l’Empire Electronix M712 et la tablette iNet D978 rev2, ainsi que l’Orange Pi PC Plus, Orange Pi 2, Orange Pi Plus 2E, Orange Pi Lite, Olimex A33-Olinuxino et le Nano Pi Neo ;
• les cartes Broadcom incluant les cartes de références BCM958525er, BCM958522er, BCM988312hr, BCM958623hr et BCM958622hr ;
• le routeur NETGEAR WNR854T ;
• le LG Nexus 5 ;
• la Beagleboard-x15 rev B1 ;
• la conversion vers l’arborescence matérielle DeviceTree pour mach-omap2 est complète, incluant une gestion complète du vénérable Nokia N900.

Autres nouveautés

Pilote de test EFI

Ce pilote, soumis par Ingo Molnar, mais dont Canonical assure la maintenance, est désormais inclus dans le noyau dans le but d’aider les développeurs de micrologiciels (firmwares). Il exporte en espace utilisateur les interfaces du service d’exécution UEFI et est utilisé par la suite de test de micrologiciels (FTWS).

Plate‐forme Mellanox

Un correctif, également proposé par Ingo Molnar, marque le début de la prise en charge de la plate‐forme Mellanox, utilisée principalement dans les domaines du calcul à haute performance et les centres de traitement de données (data centers). Ces plates‐formes ne sont pas données, par exemple, le commutateur réseau MSX6710 à 36 ports coûte la bagatelle de 11 900 US$. Mellanox est un fournisseur de matériel haut de gamme InfiniBand et Ethernet pour serveurs et plates‐formes de stockage en masse.

MD RAID

Le code de MD RAID ajoute la prise en charge de AXV512 pour accélérer le RAID 6 et d’autres améliorations pour la création d’un volume.

NVDIMM

Le code NVDIMM ajoute plus de flexibilité dans la prise en charge de ces zones de mémoire non volatile exportées par ACPI. Michael Larabel en écrit un bref récapitulatif sur son site, Phoronix.

Intel Integrated Sensor Hub (ISH)

Linux 4.9 prend également en charge le module ISH (Integrated Sensor Hub) d’Intel, un capteur intégré en remplacement de capteurs externes. Ces capteurs détectent, par exemple, le changement de position de l’appareil, contribuent à l’ajustement automatique de la luminosité et interviennent également dans la gestion de l’énergie sur les ordinateurs portables. Ce correctif est destiné à la famille de processeurs Cherry Trail et suivantes.

Intel Atom

Un nouvel algorithme de gestion du P-state (une collection de niveaux prédéfinis pour la gestion de l’énergie) a été soumis par Rafael J. Wysocki. En outre, il améliore les performances des processeurs Intel Atom en baissant moins fortement le niveau d’énergie. L’idée est d’ajouter 50 % à l’objectif de performance calculé pour diminuer le coût de migration d’un processus vers un autre cœur.

Projet ARA de Google

Le pilote qui gère Greybus, conçu sur les bases du protocole UniPro, a été ajouté au noyau Linux.

Unipro ?

UniPro est un protocole de communication, comme I²C, destiné à l’interconnexion de divers circuits intégrés. Il est destiné à être utilisé dans le monde des ordiphones.

Il est notamment utilisé par Google pour son projet ARA qui vise à créer un ordiphone modulaire. On peut le retrouver dans un produit grand public commercialisé : le téléphone Lenovo Moto Z utilise ce bus pour ses Moto Mods.

Les différentes versions du protocole UniPro ont été créées par la MIPI Alliance (Mobile Industry Processor Interface Alliance) composée de 250 entreprises. Le protocole a été créé en 2006.

Unipro est un protocole de transmission à haute vitesse et de faible consommation électrique. Il prend en charge jusqu’à 128 périphériques. Il respecte les standards de l’OSI.

 Greybus ?

Greybus est une couche applicative pour UniPro ce qui correspond à la septième couche du modèle OSI. C’est un bus générique initialement transporté sur USB, avec des notions de « cports » et de liens logiques correspondants aux liens UniPro, mais il a été conçu pour ne pas être dépendant du lien physique.

L’implémentation dans Linux suppose une communication avec un « SVC » qui, dans le téléphone ARA, est un microcontrôleur utilisé pour gérer le routage des liens logiques vers les cports des périphériques UniPro.

Il y a par exemple des implémentations 100 % USB avec un démultiplexage des cports dans un micrologiciel sur un STM32F4 ou, plus récemment, une implémentation d’un routage Greybus en espace utilisateur via Netlink, et une communication par Bluetooth avec des modules. Cela donne en pratique des interfaces virtuelles locales vers des périphériques distants. Par exemple, GreyBus permettait d’exposer le bus I²C ou SPI des modules et de les contrôler avec les API I²C ou SPI de Linux, ou même d’y associer des pilotes classiques.

UniPro, quant à lui, se situe au niveau de la couche physique, soit la première couche du modèle OSI.

Ci‐dessous la mise en œuvre de Greybus dans le noyau Linux :

Voir aussi :

• [modular phones forum] Greybus protocol – an application layer for UniPro. Project Ara Developers Conference (January 2015, Singapore). Part 3.6. ;
• [Wikipédia] UniPro ;
• [kernel-recipes.org] An Introduction to Greybus ;
• [Wikipédia] MIPI Alliance ;
• [MIPI Alliance] UniPro(SM) Specifications.

Commande perf

Parmi les améliorations apportées à l’outil en ligne de commande perf, on peut lister la gestion de fichiers JSON pour décrire les évènements de l’unité de supervision des performances (PMU — Performance Monitor Unit), un nouvel ensemble d’astuces et le début du travail pour la gestion de Clang/LLVM demande d’intégration.

KThread

L’API KThread a reçu un gros coup de nettoyage.

Clef de protection mémoire

Attendue depuis un moment, la nouvelle interface MPK (Memory Protection Keys ou clefs de protection de la mémoire) est maintenant terminée et intégrée à Linux 4.9, d’après le correctif envoyé par Thomas Gleixner. Ce système définit un ensemble d’interfaces en espace utilisateur (lire des appels système) et offre aux applications un mécanisme de protection des données par page, à l’aide de clefs de chiffrement. Cette protection sera mise en application dans les futurs processeurs de la firme Intel. On peut lire, sur le site Phoronix, comment la mettre en œuvre en langage C.

Virtualisation Xen et KVM

La plate‐forme de virtualisation Xen a reçu un correctif qui introduit une fonctionnalité fort intéressante : les connexion et déconnexion à chaud du processeur (c.‐à‐d. pendant que la machine fonctionne) — sur les cartes‐mères qui en possèdent plus d’un, bien entendu. Quant à KVM, autre plate‐forme de virtualisation, ce sont des améliorations sur l’architecture ARM qui ont été apportées. À noter également un travail préparatoire sur l’adressage virtuel étendu (EVA) pour les processeurs MIPS.

Virtual mapped stack

Andy Lutomirski a introduit un nouveau mécanisme de gestion des piles noyau, qui a pour effet secondaire d’optimiser la création de tâches par la mise en cache de deux piles de fil d’exécution par processeur. Initialement, ce correctif a pour but de faciliter le diagnostic et de sécuriser l’interception des débordements de pile, ce qui devrait aussi rendre leur exploitation (exploit) plus difficile. Une pile virtuelle est encadrée par des pages de garde et les débordements sont interceptés immédiatement par le noyau, au lieu de provoquer des corruptions mémoire extrêmement difficiles à diagnostiquer. Ce genre de fonctionnalités était fourni par les correctifs de grsecurity.

Lire également les articles sur les sites Phoronix et LWN.net.

Statistiques

Entreprises ayant participé à cette version

En nombre de lignes changées

AMD sort en première position avec 105 820 lignes modifiées soit 11,1 % du total de lignes modifiées, suivie de très près par Red Hat avec 104 492 lignes, soit 10,9 %. Intel s’en sort en troisième positon avec 89 456 lignes, soit 9,4 % du total (cf. l’article de Jonathan Corbet Development statistics for 4.9 sur LWN.net).

Aller plus loin

• Dépêches des noyaux précédents (323 clics)
• Site officiel du noyau Linux (243 clics)
• Les nouveautés du noyau 4.9 (542 clics)