Linus Torvalds, le créateur et mainteneur du noyau Linux, a annoncé la sortie de la version 6.6, après avoir épuisé toutes les excuses pour retarder le travail. Cette nouvelle mouture apporte plusieurs nouveautés et améliorations, notamment au niveau de la sécurité, du support matériel et des performances. L'une des nouvelles fonctionnalités les plus notables de Linux 6.6 est le planificateur EEVDF, qui remplace le planificateur CFS.EEVDF remplit le même rôle que CFS, en aidant à diviser le temps CPU entre les processus, mais le fait plus efficacement, avec moins de décalage et une latence réduite. Cependant, les développeurs du noyau préviennent que le nouveau planificateur peut, dans de rares cas, entraîner des régressions de performances avec des charges de travail spécifiques – mais cela sera corrigé à temps.
Parmi les principales fonctionnalités de Linux 6.6, on peut citer l’implémentation de la Intel Shadow Stack (qui malgré son nom profite également à certaines puces AMD), une technologie de sécurité matérielle qui protège les applications contre les attaques de programmation orientée retour (ROP pour return-oriented programming) sur les processeurs Intel Tiger Lake et versions ultérieures.
La ROP est une technique d'exploitation avancée de type dépassement de pile (stack overflow) permettant l'exécution de code par un attaquant et ce en s'affranchissant plus ou moins efficacement des mécanismes de protection tels que l'utilisation de zones mémoires non-exécutables, l'utilisation d'un espace d'adressage aléatoire (Address Space Layout Randomization, ASLR) ou encore la signature de code. Cette technique permet à un attaquant d'obtenir le contrôle de la pile d'exécution (call stack) d'un programme, d'en rediriger les flux et, in fine, exécuter une suite de courtes instructions situées en zone mémoire exécutable, appelées « gadgets ».
Linux 6.6 introduit également un nouveau pilote firmware-attributes qui permet de modifier les paramètres du BIOS depuis Linux sur les appareils HP, un nouveau sous-système eventfs qui améliore l’efficacité mémoire du sous-système de traçage, et de nouveaux pilotes IIO et Intel IVSC MEI.
Linux 6.6 apporte aussi des améliorations pour le support des appareils ASUS, notamment la possibilité de changer le mode de chargeur, le ventilateur central et les paramètres eGPU. Les ordinateurs portables Lenovo bénéficient d’un meilleur contrôle du rétroéclairage du clavier sur certains modèles IdeaPad. Les dispositifs Mellanox sont mieux pris en charge, ainsi que les interfaces device tree, le randomisation de l’espace d’adressage du noyau (KASLR), et l’allocateur BPF prog pack sur l’architecture RISC-V.
Du côté des systèmes de fichiers, Linux 6.6 apporte des améliorations pour le support des périphériques à zones et la compression pour le F2FS, le support des mmaps partagés en mode no-cache pour le FUSE, des corrections pour netfilter et BPF, de nombreuses corrections pour le pilote AMDGPU, des corrections de régression pour le support MIDI 2.0, et une meilleure gestion de l’énergie Intel RAPL.
Linux 6.6 ajoute aussi un compilateur just-in-time BPF pour l’architecture PA-RISC, le support du hotplug SMT pour l’architecture PowerPC, un nouveau drapeau pour l’API mount qui empêche un montage de partager des superblocks en mémoire avec d’autres montages, le support des invités SEV-SNP et TDX sur Hyper-V, et le support initial des opérations réseau pour le sous-système io_uring.
Les outils KASAN, KCOV, KDB, KFENCE, KGDB, et autres sont désormais supportés sur l’architecture LoongArch. Le pilote ublk pour les périphériques à blocs en espace utilisateur prend en charge les périphériques de stockage à zones. Le système de fichiers tmpfs supporte désormais les quotas, le direct I/O, et les attributs étendus. Le serveur NFS intégré au noyau supporte les délégations d’écriture NFSv4. Le système de fichiers SMB3 intégré au noyau depuis Linux 5.15 est enfin considéré comme stable.
Enfin, Linux 6.6 améliore la prise en charge matérielle grâce au support du gadget USB MIDI 2, du codec audio Cirrus Logic CS42L43, des LED GMC (Group Multi-Color), du contrôleur GameSir T4 Kaleid, et des GPU NVIDIA T4 avec la réinitialisation secondaire du bus.
Certains noteront également la suppression des références à la National Security Agency (NSA) des États-Unis, qui a développé il y a longtemps le module Security-Enhanced Linux (SELinux) – appelé « NSA SELinux » dans le texte d'aide et les commentaires. Une modification apportée à cette partie du noyau la rebaptise simplement « SELinux » – une réaction au rôle de l'Agence dans des opérations qui ont porté atteinte à la vie privée, selon Edward Snowden.
Un planificateur CPU EEVDF pour Linux
CFS et contraintes de planification
L’un des principaux objectifs de conception de CFS était, comme on peut le comprendre à partir de son nom, l’équité - garantir que chaque processus du système obtienne sa part équitable de temps CPU. Cet objectif est atteint en suivant le temps que chaque processus a reçu et en exécutant ceux qui ont reçu moins de temps CPU que les autres, avec le temps d’exécution de chaque processus pondéré par sa priorité “nice”. CFS est, en d’autres termes, un ordonnanceur à file d’attente équitable pondérée à son cœur.
L’équité, il s’avère, est suffisante pour résoudre de nombreux problèmes de planification du CPU. Il existe cependant de nombreuses contraintes qui dépassent la répartition équitable du temps CPU et qui sont imposées à l’ordonnanceur. Il doit, par exemple, maximiser les avantages des caches mémoire du système, ce qui nécessite de minimiser le déplacement des processus entre les CPU. En même temps, cependant, il doit garder tous les CPU occupés s’il y a du travail à faire pour eux. La gestion de l’énergie est une complication supplémentaire ; parfois, les décisions optimales pour le débit du système doivent céder la place à la préservation de la durée de vie de la batterie. Les systèmes hybrides (où tous les CPU ne sont pas identiques) ajoutent plus de complications. Et ainsi de suite.
Un domaine où il y a un désir d’amélioration est le traitement des exigences de latence. Certains processus peuvent ne pas avoir besoin de beaucoup de temps CPU mais, lorsqu’ils en ont besoin, ils en ont besoin rapidement. D’autres peuvent avoir besoin de plus de temps CPU mais peuvent attendre si nécessaire. CFS ne donne pas aux processus un moyen d’exprimer leurs besoins en latence ; les valeurs nice (priorités) peuvent être utilisées pour donner à un processus plus de temps CPU, mais ce n’est pas la même chose. Les classes d’ordonnancement en temps réel peuvent être utilisées pour les travaux sensibles à la latence, mais l’exécution dans une classe en temps réel est une opération privilégiée, et les processus en temps réel peuvent affecter négativement le fonctionnement du reste du système.
Ce qui manque, c’est un moyen de garantir que certains processus puissent accéder rapidement à un CPU sans leur donner nécessairement la possibilité d’obtenir plus que leur part équitable de temps CPU. Les patches latency nice circulent depuis un certain temps comme une tentative de résoudre ce problème ; ils permettent aux processus CFS ayant des besoins de latence serrés de sauter la file d’attente pour le CPU lorsqu’ils veulent s’exécuter. Ces patches semblent fonctionner, mais Peter Zijlstra pense qu’il pourrait y avoir une meilleure approche du problème.
Introduction à EEVDF
L’algorithme d’ordonnancement “Earliest Eligible Virtual Deadline First” (EEVDF) n’est pas nouveau ; il a été décrit dans un article de 1995 par Ion Stoica et Hussein Abdel-Wahab. Son nom suggère quelque chose de similaire à l’algorithme Earliest Deadline First utilisé par l’ordonnanceur deadline du noyau mais, contrairement à cet ordonnanceur, EEVDF n’est pas un ordonnanceur en temps réel, il fonctionne donc différemment. Comprendre EEVDF nécessite de maîtriser quelques concepts (relativement) simples.
Comme CFS, EEVDF essaie de diviser le temps CPU disponible équitablement entre les processus qui sont en concurrence pour l’obtenir. Si, par exemple, il y a cinq processus qui essaient de s’exécuter sur un seul CPU, chacun de ces processus devrait obtenir 20 % du temps disponible. La valeur nice d’un processus donné peut être utilisée pour ajuster le calcul de ce que son temps équitable est ; un processus ayant une valeur nice plus faible (et donc une priorité plus élevée) a droit à plus de temps CPU au détriment de ceux ayant des valeurs nice plus élevées. Jusque-là, il n’y a rien de nouveau.
Imaginons une période d’une seconde ; pendant ce temps, dans notre scénario à cinq processus, chaque processus aurait dû obtenir 200 ms de temps CPU. Pour un certain nombre de raisons, les choses ne se passent jamais exactement de cette façon ; certains processus auront eu trop de temps, tandis que d’autres auront été lésés. Pour chaque processus, EEVDF calcule la différence entre le temps que ce processus aurait dû obtenir et le temps qu’il a réellement obtenu ; cette différence est appelée “lag”. Un processus ayant une valeur de lag positive n’a pas reçu sa part équitable et doit être ordonnancé plus tôt qu’un processus ayant une valeur de lag négative.
En fait, un processus est considéré comme “éligible” si - et seulement si - son lag calculé est supérieur ou égal à zéro ; tout processus ayant un lag négatif ne sera pas éligible à s’exécuter. Pour tout processus non éligible, il y aura un moment dans le futur où le temps auquel il a droit rattrapera le temps qu’il a réellement obtenu et il redeviendra éligible ; ce moment est considéré comme le “temps éligible”.
Le calcul du lag est donc une partie essentielle de l’ordonnanceur EEVDF, et une grande partie du jeu de patches est consacrée à trouver cette valeur correctement. Même en l’absence de l’algorithme EEVDF complet, le lag d’un processus peut être utilisé pour le placer équitablement dans la file d’attente ; les processus ayant un lag plus élevé doivent être exécutés en premier dans le but d’égaliser les valeurs de lag dans le système.
L’autre facteur qui entre en jeu est la “date limite virtuelle”, qui est le moment le plus proche auquel un processus devrait avoir reçu son temps CPU dû. Cette date limite est calculée en ajoutant la tranche de temps d’un processus à son temps éligible. Un processus ayant une tranche de temps de 10 ms, et dont le temps éligible est de 20 ms dans le futur, aura une date limite virtuelle qui est de 30 ms dans le futur.
Le cœur de EEVDF, comme on peut le voir dans son nom, est qu’il exécutera le processus ayant la date limite virtuelle la plus proche en premier. Le choix de l’ordonnancement est donc guidé par une combinaison d’équité (la valeur du lag qui est utilisée pour calculer le temps éligible) et du temps dont chaque processus dispose actuellement.
Résoudre le problème de la latence
Avec ce framework en place, la mise en œuvre d’un accès plus rapide pour les processus sensibles à la latence se fait naturellement. Lorsque l’ordonnanceur calcule la tranche de temps pour chaque processus, il prend en compte la valeur de latence-nice attribuée à ce processus ; un processus ayant une valeur de latence-nice plus faible (et donc des exigences de latence plus serrées) obtiendra une tranche de temps plus courte. Les processus qui sont relativement indifférents à la latence recevront des tranches plus longues. Notez que la quantité de temps CPU accordée à deux processus quelconques (ayant la même valeur nice) sera la même, mais que le processus à faible latence l’obtiendra en un plus grand nombre de tranches plus courtes.
Rappelez-vous que la date limite virtuelle est calculée en ajoutant la tranche de temps au temps éligible. Cela fera en sorte que les processus ayant des tranches de temps plus courtes aient des dates limites virtuelles plus proches et, par conséquent, qu’ils soient exécutés en premier. Les processus sensibles à la latence, qui n’ont normalement pas besoin de grandes quantités de temps CPU, pourront réagir rapidement aux événements, tandis que les processus sans exigences de latence se verront attribuer des tranches de temps plus longues, ce qui peut aider à améliorer le débit. Aucune heuristique complexe n’est nécessaire pour obtenir ce résultat.
Il y a cependant une grande distance entre un article académique et une implémentation qui peut fonctionner correctement dans le noyau Linux. Zijlstra n’a fait que commencer à exécuter des benchmarks sur son ordonnanceur EEVDF ; sa conclusion initiale est « qu'il y a un tas de gains et de pertes, mais rien qui indique un échec total ». Certains des résultats, a-t-il dit, « semblent indiquer que EEVDF ordonnance beaucoup plus régulièrement que CFS et a un tas de gains de latence ».
Tout en reconnaissant qu’il s’agit d’un point de départ raisonnable, Zijlstra reconnaît qu’il reste encore beaucoup de travail à faire. Mais, a-t-il dit, « si nous réussissons à faire cela, nous pouvons supprimer tout un tas de code heuristique dégoûtant », en le remplaçant par une politique mieux définie. Ce n’est pas un petit changement, a-t-il ajouté : 1 Il remanie complètement l’ordonnanceur de base, le placement, la préemption, le choix - tout. La seule chose qu’ils ont en commun, c’est qu’ils sont tous les deux basés sur un temps virtuel ».
Source : annonce Linus Torvald
Et vous ?
Que pensez-vous de la Shadow Stack, la technologie de sécurité matérielle qui protège les processeurs contre les attaques par dépassement de pile ? Quels sont les avantages et les inconvénients du sous-système eventfs qui améliore l’efficacité mémoire du sous-système de traçage ? Comment utilisez-vous le nouveau pilote firmware-attributes qui permet de modifier les paramètres du BIOS depuis Linux sur les appareils HP ? Quelles sont vos impressions sur le système de fichiers SMB3 intégré au noyau depuis Linux 5.15 et qui est enfin considéré comme stable ? Quels sont les périphériques ou les fonctionnalités que vous aimeriez voir supportés par le noyau Linux dans les prochaines versions ?