4.9. Noyau
Version du noyau dans RHEL 9.0
Red Hat Enterprise Linux 9.0 est distribué avec la version 5.14.0-70 du noyau.
Red Hat, par défaut, active eBPF dans toutes les versions de RHEL pour les utilisateurs privilégiés uniquement
Extended Berkeley Packet Filter (eBPF) est une technologie complexe qui permet aux utilisateurs d'exécuter un code personnalisé à l'intérieur du noyau Linux. En raison de sa nature, le code eBPF doit passer par le vérificateur et d'autres mécanismes de sécurité. Il y a eu des cas de vulnérabilités et d'expositions communes (CVE), où des bogues dans ce code pouvaient être utilisés pour des opérations non autorisées. Pour atténuer ce risque, Red Hat a activé par défaut eBPF dans toutes les versions de RHEL pour les utilisateurs privilégiés uniquement. Il est possible d'activer eBPF pour les utilisateurs non privilégiés en utilisant le paramètre de ligne de commande kernel. unprivileged_bpf_disabled=0.
Il convient toutefois de noter que
-
L'application de
unprivileged_bpf_disabled=0disqualifie votre noyau de la prise en charge par Red Hat et expose votre système à des risques de sécurité. -
Red Hat vous conseille vivement de traiter les processus ayant la capacité
CAP_BPFcomme si cette capacité était égale àCAP_SYS_ADMIN. -
Le réglage de
unprivileged_bpf_disabled=0ne sera pas suffisant pour exécuter de nombreux programmes BPF par des utilisateurs non privilégiés, car le chargement de la plupart des types de programmes BPF nécessite des capacités supplémentaires (généralementCAP_SYS_ADMINouCAP_PERFMON).
Pour plus d'informations sur l'application des paramètres de la ligne de commande du noyau, voir Configuration des paramètres de la ligne de commande du noyau.
(BZ#2091643)
Red Hat ne protège les symboles du noyau que pour les versions mineures
Red Hat garantit qu'un module du noyau continuera à se charger dans toutes les mises à jour futures au sein d'une version Extended Update Support (EUS), uniquement si vous compilez le module du noyau à l'aide de symboles protégés du noyau. Il n'y a pas de garantie d'ABI (Application Binary Interface) du noyau entre les versions mineures de RHEL 9.
Noyaux RHEL 9 Beta signés avec des certificats SecureBoot de confiance
Auparavant, les versions bêta de RHEL exigeaient des utilisateurs qu'ils inscrivent une clé publique bêta distincte à l'aide de la fonction MOK (Machine Owner Key). À partir de RHEL 9 Beta, les noyaux sont signés avec des certificats SecureBoot approuvés, et les utilisateurs n'ont donc plus besoin d'enregistrer une clé publique Beta distincte pour utiliser les versions Beta sur des systèmes dont l'UEFI Secure Boot est activé.
cgroup-v2 activé par défaut dans RHEL 9
La fonctionnalité des groupes de contrôle version 2 (cgroup-v2) met en œuvre un modèle hiérarchique unique qui simplifie la gestion des groupes de contrôle. Elle garantit également qu'un processus ne peut être membre que d'un seul groupe de contrôle à la fois. L'intégration approfondie avec systemd améliore l'expérience de l'utilisateur final lors de la configuration du contrôle des ressources sur un système RHEL.
Le développement de nouvelles fonctionnalités est principalement effectué pour cgroup-v2, qui possède certaines fonctionnalités manquantes dans cgroup-v1. De même, cgroup-v1 contient certaines fonctionnalités héritées du passé qui sont absentes de cgroup-v2. En outre, les interfaces de contrôle sont différentes. Par conséquent, les logiciels tiers qui dépendent directement de cgroup-v1 peuvent ne pas fonctionner correctement dans l'environnement cgroup-v2.
Pour utiliser cgroup-v1, vous devez ajouter les paramètres suivants à la ligne de commande du noyau :
systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller
cgroup-v1 et cgroup-v2 sont tous deux pleinement activés dans le noyau. Il n'y a pas de version de groupe de contrôle par défaut du point de vue du noyau, et c'est systemd qui décide du montage au démarrage.
Modifications du noyau susceptibles d'affecter les modules tiers du noyau
Les distributions Linux dont la version du noyau est antérieure à la version 5.9 prenaient en charge l'exportation des fonctions GPL en tant que fonctions non GPL. Par conséquent, les utilisateurs pouvaient lier des fonctions propriétaires à des fonctions GPL du noyau par le biais du mécanisme shim. Avec cette version, le noyau RHEL incorpore des changements en amont qui améliorent la capacité de RHEL à appliquer la GPL en repoussant shim.
Les partenaires et les fournisseurs de logiciels indépendants (ISV) devraient tester leurs modules de noyau avec une version préliminaire de RHEL 9 pour s'assurer de leur conformité avec la GPL.
L'architecture ARM 64 bits a une taille de page de 4 Ko dans RHEL 9
Red Hat a sélectionné une taille de page de mémoire physique de 4 Ko pour l'architecture ARM 64 bits dans Red Hat Enterprise Linux 9. Cette taille correspond bien aux charges de travail et aux quantités de mémoire présentes sur la majorité des systèmes basés sur ARM. Pour utiliser efficacement des tailles de page importantes, utilisez l'option "huge pages" pour traiter une plus grande quantité de mémoire ou des charges de travail avec de grands ensembles de données.
Pour plus d'informations sur les grandes pages, voir Surveillance et gestion de l'état et des performances du système.
(BZ#1978382)
L'utilitaire strace affiche désormais correctement les incompatibilités de contexte SELinux
L'option --secontext de strace a été complétée par le paramètre mismatch. Ce paramètre permet d'imprimer le contexte attendu en même temps que le contexte réel en cas de non-concordance uniquement. La sortie est séparée par un double point d'exclamation (!!), d'abord le contexte réel, puis le contexte attendu. Dans les exemples ci-dessous, les paramètres full,mismatch affichent le contexte complet attendu en même temps que le contexte réel parce que la partie utilisateur des contextes ne correspond pas. Cependant, lors de l'utilisation d'un mismatch solitaire, il ne vérifie que la partie type du contexte. Le contexte attendu n'est pas imprimé car la partie type des contextes correspond.
[...] $ strace --secontext=full,mismatch -e statx stat /home/user/file statx(AT_FDCWD, "/home/user/file" [system_u:object_r:user_home_t:s0!!unconfined_u:object_r:user_home_t:s0], ... $ strace --secontext=mismatch -e statx stat /home/user/file statx(AT_FDCWD, "/home/user/file" [user_home_t:s0], ...
Les erreurs de contexte SELinux sont souvent à l'origine de problèmes de contrôle d'accès associés à SELinux. Les incohérences indiquées dans les traces d'appels système peuvent accélérer considérablement les vérifications de l'exactitude du contexte SELinux. Les traces d'appels système peuvent également expliquer le comportement spécifique du noyau en ce qui concerne les vérifications du contrôle d'accès.
perf-top peut maintenant être trié par une certaine colonne
Avec cette mise à jour de l'outil de profilage du système perf-top, vous pouvez trier les échantillons en fonction d'une colonne d'événements arbitraire. Auparavant, les événements étaient triés par la première colonne dans le cas où plusieurs événements d'un groupe étaient échantillonnés. Pour trier les échantillons, utilisez l'option de ligne de commande --group-sort-idx et appuyez sur une touche numérique pour trier le tableau par la colonne de données correspondante. Notez que la numérotation des colonnes commence à 0.
(BZ#1851933)
Nouveau paquet : jigawatts
Checkpoint/Restore In Userspace (CRIU) est un utilitaire Linux qui permet de vérifier et de restaurer des processus. Le paquetage jigawatts contient une bibliothèque Java qui vise à améliorer l'utilisation des mécanismes CRIU à partir d'applications Java.
La commande trace-cmd reset a un nouveau comportement
Auparavant, la commande trace-cmd reset réinitialisait la configuration de tracing_on à 0. Le nouveau comportement de trace-cmd reset est de réinitialiser tracing_on à sa valeur par défaut 1.
(BZ#1933980)
Le filtre de paquets Berkeley étendu est pris en charge dans RHEL 9
Le site Extended Berkeley Packet Filter (eBPF) est une machine virtuelle intégrée au noyau qui permet l'exécution de code dans l'espace du noyau, dans l'environnement restreint du bac à sable, avec un accès à un ensemble limité de fonctions. La machine virtuelle exécute un code spécial de type assemblage.
Le bytecode eBPF est d'abord chargé dans le noyau. Ensuite, le bytecode est vérifié et traduit en code machine natif avec une compilation juste à temps. Enfin, la machine virtuelle exécute le code.
Red Hat fournit de nombreux composants qui utilisent la machine virtuelle eBPF. Dans RHEL 9, ces composants incluent :
- Le paquet BPF Compiler Collection (BCC), qui fournit des outils pour l'analyse des E/S, la mise en réseau et la surveillance des systèmes d'exploitation Linux utilisant eBPF.
- La bibliothèque BCC, qui permet de développer des outils similaires à ceux fournis dans le paquet d'outils BCC.
-
Le langage de traçage
bpftrace. Le paquet
libbpf, qui est essentiel pour le développement debpfet les applications liées àbpfcommebpftrace.-
Les parties de l'API
XDPetAF_XDPde la bibliothèquelibbpfne sont pas prises en charge et pourraient être supprimées dans une prochaine version.
-
Les parties de l'API
- La fonction eBPF for Traffic Control (tc), qui permet un traitement programmable des paquets à l'intérieur du chemin de données du réseau du noyau.
-
La fonction eXpress Data Path (XDP), qui permet d'accéder aux paquets reçus avant que la pile réseau du noyau ne les traite. Red Hat prend en charge XDP uniquement s'il est utilisé par le biais de la bibliothèque
libxdp. Le paquet
xdp-tools, qui contient des utilitaires de prise en charge de l'espace utilisateur pour la fonctionnalité XDP et qui est pris en charge par les architectures AMD64 et Intel64. Le paquetagexdp-toolscomprend :-
La bibliothèque
libxdp. -
L'utilitaire
xdp-loaderpour le chargement des programmes XDP. -
Le programme d'exemple
xdp-filterpour le filtrage de paquets. -
L'utilitaire
xdpdumppour capturer les paquets d'une interface réseau avec XDP activé. L'utilitairexdpdumpn'est actuellement pris en charge que sur les architectures AMD64 et Intel64. Il est disponible pour d'autres architectures en tant qu'aperçu technologique.
-
La bibliothèque
-
La prise
AF_XDPpour connecter le chemin eXpress Data Path (XDP) à l'espace utilisateur.
RHEL 9 fournit l'utilitaire crash version 8.0.0
RHEL 9 est distribué avec l'utilitaire crash version 8.0.0. Les corrections de bogues et les améliorations notables sont les suivantes :
-
Ajoute le nouveau paramètre
offsetdans la commandeadd-symbol-file. Ce support permet d'établir le lien entrekaslr_offsetetgdb. -
Mise à jour du site
gdb-7.6versgdb-10.2.
(BZ#1896647)
makedumpfile prend désormais en charge une capacité de compression améliorée de zstd
Avec cette amélioration, le site makedumpfile inclut désormais la capacité de compression Zstandard (zstd), qui offre des taux de compression élevés. Cette amélioration est particulièrement utile pour les systèmes à grande mémoire.
La capacité de compression de zstd présente désormais un bon équilibre entre la taille du vidage de vmcore et la durée de la compression par rapport aux taux de compression précédents. En conséquence, le mécanisme de compression amélioré crée maintenant un fichier vmcore plus petit avec un temps de compression acceptable.
Notez qu'un bon taux de compression dépend également de la manière dont le système est utilisé et du type de données stockées dans la mémoire vive.
(BZ#1988894)
numatop activé sur les processeurs de serveurs évolutifs Intel Xeon
numatop est un outil qui suit et analyse le comportement des processus et des threads s'exécutant sur des systèmes NUMA et affiche des mesures permettant d'identifier les goulets d'étranglement liés aux performances des NUMA.
numatop utilise les technologies d'échantillonnage des compteurs de performance d'Intel et associe les données de performance aux informations du système Linux runtime, afin de fournir une analyse des systèmes de production.
(BZ#1874125)
kexec_file_load a été ajouté comme option par défaut pour RHEL 9
Cette mise à jour ajoute l'appel système kexec_file_load pour l'architecture ARM 64 bits. Elle fournit un chargeur in-kernel kexec pour kdump. Auparavant, le noyau empêchait le chargement d'images de noyau non signées lorsque l'option de démarrage sécurisé était activée. Le mécanisme kdump essayait d'abord de détecter si l'amorçage sécurisé était activé et choisissait ensuite l'interface d'amorçage à exécuter. Par conséquent, un noyau non signé ne parvenait pas à se charger lorsque l'amorçage sécurisé était activé et que kexec_file_load() était spécifié.
Cette mise à jour corrige le problème et un noyau non signé fonctionne correctement dans le scénario décrit.
(BZ#1895232)
makedumpfile inclut désormais des options améliorées pour obtenir une estimation de la taille de vmcore
Avec cette implémentation, l'utilitaire makedumpfile inclut maintenant les options suivantes qui aident à imprimer une estimation de la taille du dump pour le noyau en cours d'exécution :
-
--dry-runeffectue toutes les opérations spécifiées par les autres options mais n'écrit pas le fichier de sortie. -
--show-statsimprime les messages du rapport. Il s'agit d'une alternative à l'activation du bit 4 dans l'option level provided to--message-level.
L'exemple suivant montre l'utilisation de --dry-run et --show-stats:
$ makedumpfile --dry-run --show-stats -l --message-level 7 -d 31 /proc/kcore dump.dummy
Notez que la taille du fichier dump peut varier en fonction de l'état du système au moment de la panique et que l'estimation fournie par les options peut différer de l'état réel.
Le paquet kexec-tools prend désormais en charge les valeurs de réservation de mémoire par défaut de crashkernel pour RHEL 9
Le paquetage kexec-tools conserve désormais les valeurs par défaut de réservation de la mémoire crashkernel. Le service kdump utilise la valeur par défaut pour réserver la mémoire crashkernel pour chaque noyau. Cette implémentation améliore également l'allocation de la mémoire pour kdump lorsqu'un système dispose de moins de 4 Go de mémoire disponible.
Pour demander la valeur par défaut du crashkernel :
$ kdumpctl get-default-crashkernel
Si la mémoire réservée par la valeur par défaut crashkernel n'est pas suffisante sur votre système, augmentez le paramètre crashkernel.
Notez que l'option crashkernel=auto de la ligne de commande de démarrage n'est plus prise en charge dans RHEL 9 et les versions ultérieures.
Pour plus d'informations, voir le fichier /usr/share/doc/kexec-tools/crashkernel-howto.txt.
(BZ#2034490)
L'ordonnancement des noyaux est pris en charge dans RHEL 9
Grâce à la fonctionnalité de planification de base, les utilisateurs peuvent empêcher les tâches qui ne devraient pas se faire confiance de partager le même cœur d'unité centrale. De même, les utilisateurs peuvent définir des groupes de tâches qui peuvent partager un cœur d'unité centrale.
Ces groupes peuvent être spécifiés :
- Améliorer la sécurité en atténuant certaines attaques SMT (Multithreading symétrique)
- Pour isoler les tâches qui nécessitent un cœur entier. Par exemple, pour les tâches dans des environnements en temps réel, ou pour les tâches qui reposent sur des caractéristiques spécifiques du processeur telles que le traitement SIMD (Single Instruction, Multiple Data)
Pour plus d'informations, voir Core Scheduling.
(JIRA:RHELPLAN-100497)
Amélioration des performances sur l'architecture ARM 64 bits en utilisant par défaut le mode iommu non strict
Avec cette mise à jour, l'architecture ARM 64 bits utilise par défaut le domaine d'accès direct à la mémoire (DMA) paresseux pour l'unité de gestion de la mémoire système (SMMU). Tout en apportant un gain de performance significatif, cela peut introduire une fenêtre entre un désappairage d'adresse et un vidage du Translation Lookaside Buffer (TLB) sur l'unité de gestion de la mémoire du système. Dans les versions précédentes, l'architecture ARM 64 bits configurait par défaut les domaines DMA stricts, ce qui entraînait une baisse des performances en raison de la taille de page de 4 Ko.
Si vous devez utiliser le mode de domaine DMA strict, spécifiez le mode iommu.strict=1 à l'aide de la ligne de commande du noyau. Notez que l'utilisation de domaines DMA stricts peut entraîner une baisse des performances sur les architectures ARM 64 bits.
(BZ#2050415)
L'arborescence des sources de kernel-rt a été mise à jour vers l'arborescence RHEL 9.0
Les sources de kernel-rt ont été mises à jour pour utiliser la dernière arborescence des sources du noyau Red Hat Enterprise Linux. Le jeu de correctifs en temps réel a également été mis à jour vers la dernière version en amont, v5.15-rt19. Ces mises à jour apportent un certain nombre de corrections de bogues et d'améliorations.
(BZ#2002474)
Prise en charge du hotplug de l'unité centrale dans les PMU hv_24x7 et hv_gpci
Avec cette mise à jour, les compteurs PMU réagissent correctement au branchement à chaud d'une unité centrale. Par conséquent, si un compteur d'événements hv_gpci fonctionne sur une unité centrale qui est désactivée, le comptage est redirigé vers une autre unité centrale.
(BZ#1844416)
Les mesures pour les événements de nidification du POWERPC hv_24x7 sont maintenant disponibles
Des mesures pour les événements de nidification POWERPC hv_24x7 sont maintenant disponibles pour perf. En agrégeant plusieurs événements, ces mesures permettent de mieux comprendre les valeurs obtenues à partir des compteurs perf et l'efficacité avec laquelle l'unité centrale est capable de traiter la charge de travail.
(BZ#1780258)
Le pilote IRDMA a été introduit dans RHEL 9
Le pilote IRDMA active la fonctionnalité RDMA sur les périphériques réseau Intel® compatibles RDMA. Les périphériques pris en charge par ce pilote sont les suivants :
- Contrôleur Ethernet Intel® E810
- Adaptateur réseau Ethernet Intel® X722
RHEL 9 propose une mise à jour du pilote Intel® Ethernet Protocol Driver for RDMA (IRDMA) pour le périphérique X722 Internet Wide-area RDMA Protocol (iWARP). RHEL 9 introduit également un nouveau périphérique E810 qui prend en charge iWARP et RDMA over Converged Ethernet (RoCEv2). Le module IRDMA remplace l'ancien module i40iw pour X722 et étend l'interface ABI (Application Binary Interface) définie pour i40iw. Ce changement est rétrocompatible avec l'ancien fournisseur RDMA-Core de X722 (libi40iw).
- L'appareil X722 ne prend en charge que l'iWARP et un ensemble plus limité de paramètres de configuration.
Le périphérique E810 prend en charge l'ensemble des fonctions RDMA et de gestion de la congestion suivantes :
- transports RDMA iWARP et RoCEv2
- Contrôle de flux prioritaire (PFC)
- Notification explicite de congestion (ECN)
(BZ#1874195)
Un nouveau paramètre pour le module kernel bonding: lacp_active
RHEL 9 introduit le paramètre lacp_active pour le module du noyau bonding. Ce paramètre indique s'il faut envoyer des trames LACPDU (Link Aggregation Control Protocol Data Unit) à des intervalles spécifiés. Les options sont les suivantes :
-
on(par défaut) - permet d'envoyer les trames LACPDU avec le paramètre configurélacp_rate -
off- les trames LACPDU jouent le rôle de "parler quand on vous parle"
Notez que les trames d'état LACPDU sont toujours envoyées lorsque vous initialisez ou libérez un port.
