Noyau Linux 5.14

Noyau Linux 5.14

AprÚs deux mois de développement, Linus Torvalds présenté version du noyau Linux 5.14. Parmi les changements notables : nouveaux appels systÚme quotactl_fd() et memfd_secret(), suppression des pilotes ide et raw, nouveau contrÎleur de priorités d'entrée/sortie pour cgroup, mode de planification des tùches SCHED_CORE, infrastructure pour créer des chargeurs de programmes BPF vérifiés.

La nouvelle version comprend 15883 corrections apportées par 2002 développeurs, la taille du patch est de 69 Mo (les modifications concernent 12580 fichiers, 861501 lignes de code ajoutées et 321654 lignes supprimées). Environ 47 % de toutes les modifications présentées dans 5.14 sont liées aux pilotes de périphériques, environ 14 % des modifications concernent la mise à jour du code spécifique aux architectures matérielles, 13 % sont liées à la pile réseau, 3 % aux systÚmes de fichiers et 3 % aux sous-systÚmes internes du noyau.

Principales nouveautés:

  • sous-systĂšme de disque, entrĂ©e/sortie et systĂšmes de fichiers :
    • pour cgroup mis en Ɠuvre nouveau contrĂŽleur de priorisation d'entrĂ©e/sortie — rq-qos, qui peut gĂ©rer la prioritĂ© de traitement des requĂȘtes aux dispositifs de bloc gĂ©nĂ©rĂ©es par les membres de chaque cgroup. Le support de ce nouveau contrĂŽleur de prioritĂ© a Ă©tĂ© ajoutĂ© au planificateur d'entrĂ©e/sortie mq-deadline ;
    • dans le systĂšme de fichiers ext4 rĂ©alisĂ©e nouvelle commande ioctl EXT4_IOC_CHECKPOINT, forçant l'Ă©criture sur disque de toutes les transactions en attente du journal et des tampons qui y sont associĂ©s, ainsi que la réécriture de la zone utilisĂ©e par le journal dans le stockage. Ce changement a Ă©tĂ© prĂ©parĂ© dans le cadre d'une initiative visant Ă  prĂ©venir les fuites d'informations des systĂšmes de fichiers ;
    • dans Btrfs ajoutĂ©s optimisations des performances : grĂące Ă  l'Ă©limination du journalisation superflue des attributs Ă©tendus lors de l'exĂ©cution de fsync, la performance des opĂ©rations intensives sur les attributs Ă©tendus a Ă©tĂ© amĂ©liorĂ©e jusqu'Ă  17 %. De plus, lors des opĂ©rations de troncation, ne touchant pas les Ă©tendues, l'exĂ©cution de la synchronisation complĂšte a Ă©tĂ© dĂ©sactivĂ©e, rĂ©duisant le temps d'exĂ©cution de l'opĂ©ration de 12 %. Une option a Ă©tĂ© ajoutĂ©e dans sysfs pour limiter la bande passante d'entrĂ©e/sortie lors de la vĂ©rification du FS. Des appels ioctl ont Ă©tĂ© ajoutĂ©s pour annuler les opĂ©rations de redimensionnement et de suppression de dispositif ;
    • dans XFS restructurĂ©e implĂ©mentation du cache tampon, qui a Ă©tĂ© rĂ©visĂ©e pour allouer des pages mĂ©moire en mode batch. L'efficacitĂ© du cache a Ă©tĂ© amĂ©liorĂ©e ;
    • Dans F2FS, une option a Ă©tĂ© ajoutĂ©e pour fonctionner en mode lecture seule et un mode de mise en cache des blocs compressĂ©s (compress_cache) a Ă©tĂ© mis en Ɠuvre pour amĂ©liorer les performances de lecture alĂ©atoire. La compression des fichiers mappĂ©s en mĂ©moire via l'opĂ©ration mmap() est prise en charge. Une nouvelle option de montage nocompress a Ă©tĂ© proposĂ©e pour dĂ©sactiver sĂ©lectivement la compression des fichiers par masque;
    • Des travaux ont Ă©tĂ© rĂ©alisĂ©s sur le pilote exFAT pour amĂ©liorer la compatibilitĂ© avec le stockage de certaines camĂ©ras numĂ©riques;
    • Un appel systĂšme a Ă©tĂ© ajoutĂ© quotactl_fd(), qui permet de gĂ©rer les quotas non pas par un fichier de pĂ©riphĂ©rique spĂ©cial, mais par la spĂ©cification d'un descripteur de fichier associĂ© au systĂšme de fichiers pour lequel le quota s'applique;
    • Les anciens pilotes pour les dispositifs de bloc avec interface IDE ont Ă©tĂ© supprimĂ©s du noyau, remplacĂ©s depuis longtemps par le sous-systĂšme libata. Le support des anciens dispositifs est conservĂ© dans son intĂ©gralitĂ©, les modifications concernent uniquement la possibilitĂ© d'utiliser les anciens pilotes, pour lesquels les stockage Ă©taient nommĂ©s /dev/hd*, et non /dev/sd*;
    • Le pilote « raw », fournissant un accĂšs non tamponnĂ© aux dispositifs de bloc via l'interface /dev/raw, a Ă©tĂ© supprimĂ© du noyau. Cette fonctionnalitĂ© est mise en Ɠuvre depuis longtemps dans les applications Ă  l'aide du drapeau O_DIRECT;
  • MĂ©moire et services systĂšme :
    • Un nouveau mode de planification SCHED_CORE, a Ă©tĂ© mis en Ɠuvre dans le planificateur de tĂąches, permettant de gĂ©rer quels processus peuvent s'exĂ©cuter en parallĂšle sur un mĂȘme cƓur CPU. À chaque processus peut ĂȘtre attribuĂ© un identifiant cookie, dĂ©finissant le domaine de confiance entre les processus (par exemple, appartenant Ă  un mĂȘme utilisateur ou conteneur). Lors de l'organisation de l'exĂ©cution du code, le planificateur peut assurer le partage d'un mĂȘme cƓur CPU uniquement pour les processus liĂ©s Ă  un mĂȘme propriĂ©taire, ce qui peut ĂȘtre utilisĂ© pour bloquer certaines attaques de type Spectre en empĂȘchant l'exĂ©cution dans un mĂȘme flux SMT (Hyper-Threading) de tĂąches dignes de confiance et non dignes de confiance;
    • Pour le mĂ©canisme cgroup, le support de l'opĂ©ration kill a Ă©tĂ© mis en Ɠuvre, permettant de terminer tous les processus liĂ©s au groupe en une seule fois (envoyer SIGKILL) en Ă©crivant « 1 » dans le fichier virtuel cgroup.kill;
    • Les capacitĂ©s liĂ©es Ă  la dĂ©tection des blocages fractionnĂ©s (« split lock »), qui se produisent lors de l'accĂšs Ă  des donnĂ©es non alignĂ©es en mĂ©moire du fait que, lors de l'exĂ©cution d'instructions atomiques, les donnĂ©es traversent deux lignes de cache du CPU, ont Ă©tĂ© Ă©tendues. De tels blocages entraĂźnent une chute significative des performances, c'est pourquoi auparavant il Ă©tait possible de forcer la fermeture de l'application Ă  l'origine du blocage. Dans cette nouvelle version, un paramĂštre de ligne de commande du noyau « split_lock_detect=ratelimit:N » a Ă©tĂ© ajoutĂ©, permettant de dĂ©finir la limite d'intensitĂ© des opĂ©rations de blocage par seconde pour l'ensemble du systĂšme. Lorsque cette limite est dĂ©passĂ©e, tout processus Ă  l'origine d'un blocage fractionnĂ© sera suspendu pendant 20 ms au lieu d'ĂȘtre arrĂȘtĂ©.
    • Dans le contrĂŽleur de bande passante CFS (CFS bandwidth controller), qui dĂ©termine combien de temps processeur peut ĂȘtre attribuĂ© Ă  chaque cgroup, il est dĂ©sormais possible de dĂ©finir des limites dĂ©terminĂ©es par une durĂ©e d'action, ce qui permet de mieux rĂ©guler les charges sensibles aux latences. Par exemple, paramĂ©trer la valeur cpu.cfs_quota_us Ă  50000 et cpu.cfs_period_us Ă  100000 permettra Ă  un groupe de processus d'utiliser 50 ms de temps CPU toutes les 100 ms.
    • ajoutĂ© Une infrastructure initiale pour crĂ©er des chargeurs de programmes BPF, qui permettra ultĂ©rieurement de n'autoriser que le chargement de programmes BPF signĂ©s par une clĂ© numĂ©rique de confiance.
    • Une nouvelle opĂ©ration futex FUTEX_LOCK_PI2 a Ă©tĂ© ajoutĂ©e, utilisant un minuteur monotone pour calculer le dĂ©lai d'expiration, tenant compte du temps passĂ© par le systĂšme en mode veille.
    • Un support pour les grandes pages mĂ©moire (Transparent Huge-Pages) et la possibilitĂ© d'appliquer le mĂ©canisme KFENCE pour la dĂ©tection d'erreurs lors de l'utilisation de la mĂ©moire.
    • Dans l'appel systĂšme madvise(), fournissant des moyens pour optimiser la gestion de la mĂ©moire du processus, ajoutĂ©es les indicateurs MADV_POPULATE_READ et MADV_POPULATE_WRITE pour gĂ©nĂ©rer des « page fault » dans toutes les pages mĂ©moire concernĂ©es pour les opĂ©rations de lecture ou d'Ă©criture, sans effectuer de lecture ou d'Ă©criture rĂ©elle (prefault). L'utilisation de ces indicateurs peut ĂȘtre utile pour rĂ©duire les latences lors du fonctionnement du programme, en permettant l'exĂ©cution anticipĂ©e du gestionnaire de « page fault » pour toutes les pages non allouĂ©es, sans attendre l’accĂšs effectif Ă  celles-ci.
    • dans le systĂšme de test unitaire kunit ajoutĂ© prise en charge du lancement de tests dans l'environnement QEMU;
    • de nouveaux traceurs ont Ă©tĂ© ajoutĂ©s : «osnoise» pour suivre les latences dans les applications causĂ©es par le traitement des interruptions, et «timerlat» pour fournir des informations dĂ©taillĂ©es sur les latences lors des rĂ©veils par signal de minuterie;
  • virtualisation et sĂ©curitĂ© :
    • ajoutĂ© appel systĂšme memfd_secret(), qui permet de crĂ©er une zone mĂ©moire privĂ©e dans un espace d'adresses isolĂ©, visible uniquement par le processus propriĂ©taire, non rĂ©percutĂ©e dans d'autres processus et directement inaccessible au noyau;
    • dans le systĂšme de filtrage des appels systĂšme seccomp, lors du dĂ©placement des gestionnaires de blocage dans l'espace utilisateur, il est dĂ©sormais possible d'utiliser une seule opĂ©ration atomique pour crĂ©er un descripteur de fichier pour la tĂąche isolĂ©e et de le renvoyer lors du traitement de l'appel systĂšme. L'opĂ©ration proposĂ©e rĂ©sout le problĂšme avec l'interruption du gestionnaire dans l'espace utilisateur lors de la rĂ©ception d'un signal;
    • ajoutĂ© un nouveau mĂ©canisme pour gĂ©rer la limitation des ressources dans l'espace de noms des identifiants utilisateur, qui lie des compteurs rlimit individuels Ă  l'utilisateur dans le «user namespace». Ce changement rĂ©sout le problĂšme de l'application de compteurs de ressources partagĂ©s lors du lancement par un utilisateur de processus dans diffĂ©rents conteneurs;
    • dans l'hyperviseur KVM pour les systĂšmes ARM64, la possibilitĂ© d'utiliser dans les systĂšmes invitĂ©s l'extension MTE (MemTag, Memory Tagging Extension) a Ă©tĂ© ajoutĂ©e, permettant d'attacher des balises Ă  chaque opĂ©ration d'allocation de mĂ©moire et d'organiser la vĂ©rification de l'utilisation correcte des pointeurs pour bloquer l'exploitation des vulnĂ©rabilitĂ©s causĂ©es par des accĂšs Ă  des blocs de mĂ©moire dĂ©jĂ  libĂ©rĂ©s, des dĂ©bordements de tampon, des accĂšs avant initialisation et une utilisation hors du contexte actuel;
    • les outils d'authentification des pointeurs fournis par la plateforme ARM64 peuvent maintenant ĂȘtre configurĂ©s sĂ©parĂ©ment pour le noyau et l'espace utilisateur. La technologie permet d'utiliser des instructions ARM64 spĂ©cialisĂ©es pour vĂ©rifier les adresses de retour Ă  l'aide de signatures numĂ©riques, qui sont stockĂ©es dans les bits supĂ©rieurs non utilisĂ©s du pointeur lui-mĂȘme;
    • dans User-mode Linux ajoutĂ© prise en charge de l'utilisation de pilotes pour des pĂ©riphĂ©riques PCI avec un bus PCI virtuel, rĂ©alisĂ© par le pilote PCI-over-virtio;
    • Un support pour le dispositif paravirtualisĂ© virtio-iommu a Ă©tĂ© ajoutĂ© pour les systĂšmes x86, permettant d'envoyer des requĂȘtes IOMMU telles que ATTACH, DETACH, MAP et UNMAP, au-dessus du transport virtio sans Ă©mulation des tables de pages mĂ©moire ;
    • Pour les processeurs Intel, depuis la famille Skylake jusqu'Ă  Coffee Lake, l'utilisation des extensions Intel TSX (Transactional Synchronization Extensions) est dĂ©sactivĂ©e par dĂ©faut, fournissant des moyens d'amĂ©liorer la performance des applications multithreads par l'exception dynamique des opĂ©rations de synchronisation excessives. Les extensions sont dĂ©sactivĂ©es en raison de la possibilitĂ© d'attaques Zombieload, manipulant les fuites d'informations par des canaux secondaires, rĂ©sultant du fonctionnement du mĂ©canisme d'interruption asynchrone des opĂ©rations (TAA, TSX Asynchronous Abort) ;
  • sous-systĂšme rĂ©seau :
    • L'intĂ©gration dans le noyau MPTCP (MultiPath TCP), une extension du protocole TCP permettant de faire fonctionner une connexion TCP avec la livraison des paquets simultanĂ©ment par plusieurs chemins Ă  travers diffĂ©rentes interfaces rĂ©seau reliĂ©es Ă  diffĂ©rentes adresses IP, se poursuit. Dans cette nouvelle version ajoutĂ© un mĂ©canisme pour dĂ©finir ses propres politiques de hachage du trafic pour IPv4 et IPv6 (multipath hash policy), permettant depuis l'espace utilisateur de dĂ©terminer quels champs des paquets, y compris les incapsulĂ©s, seront utilisĂ©s lors du calcul du hachage dĂ©terminant le chemin Ă  suivre pour le paquet ;
    • Un support pour les sockets SOCK_SEQPACKET (transmission ordonnĂ©e et fiable des datagrammes) a Ă©tĂ© ajoutĂ© au transport virtio ;
    • Les capacitĂ©s du mĂ©canisme de sockets SO_REUSEPORT ont Ă©tĂ© Ă©tendues, permettant Ă  plusieurs sockets Ă  l'Ă©coute de se connecter Ă  un mĂȘme port pour accepter les connexions avec une distribution des requĂȘtes entrantes simultanĂ©ment sur tous les sockets connectĂ©s via SO_REUSEPORT, facilitant ainsi la crĂ©ation d'applications serveur multithread. Dans cette nouvelle version ajoutĂ©es des outils pour transfĂ©rer le contrĂŽle Ă  un autre socket en cas d'Ă©chec lors du traitement d'une requĂȘte par le socket initialement sĂ©lectionnĂ© (rĂ©solvant le problĂšme de perte de connexions individuelles lors du redĂ©marrage des services) ;
  • matĂ©riel :
    • dans le pilote amdgpu rĂ©alisĂ©e prise en charge des nouvelles sĂ©ries de GPU AMD Radeon RX 6000, dĂ©veloppĂ©s sous les noms de code « Beurre Goby » (Navi 24) et « Carpe Jaune », ainsi qu'une meilleure prise en charge des GPU Aldebaran (gfx90a) et APU Van Gogh. Ajout de la possibilitĂ© de travailler simultanĂ©ment avec plusieurs panneaux eDP. Pour APU Renoir, prise en charge de l'utilisation de tampons cryptĂ©s dans la mĂ©moire vidĂ©o (TMZ, Trusted Memory Zone). Ajout de la prise en charge du retrait Ă  chaud des cartes graphiques (hot-unplug). Pour les GPU Radeon RX 6000 (Navi 2x) et les anciens GPU AMD, la prise en charge du mĂ©canisme d'Ă©conomie d'Ă©nergie ASPM (Active State Power Management) est activĂ©e par dĂ©faut, qui Ă©tait auparavant activĂ©e uniquement pour les GPU Navi 1x, Vega et Polaris;
    • pour les puces AMD, la prise en charge de la mĂ©moire virtuelle partagĂ©e (SVM, shared virtual memory) basĂ©e sur le sous-systĂšme HMM (Heterogeneous memory management) a Ă©tĂ© ajoutĂ©e, permettant d'utiliser des dispositifs avec leurs propres unitĂ©s de gestion de la mĂ©moire (MMU, memory management unit), qui peuvent accĂ©der Ă  la mĂ©moire principale. Notamment, grĂące Ă  HMM, il est possible d'organiser un espace d'adressage commun entre le GPU et le CPU, dans lequel le GPU peut accĂ©der Ă  la mĂ©moire principale du processus;
    • prise en charge initiale de la technologie AMD Smart Shift, qui change dynamiquement les paramĂštres de consommation d'Ă©nergie du CPU et du GPU sur les ordinateurs portables dotĂ©s d'un chipset et d'une carte graphique AMD pour amĂ©liorer les performances lors des jeux, du montage vidĂ©o et du rendu 3D;
    • dans le driver i915 pour les cartes graphiques Intel sont incluses. prise en charge des puces Intel Alderlake P;
    • ajout d'un driver drm/hyperv pour le pilote graphique virtuel Hyper-V;
    • ajoutĂ© driver graphique simpledrm, utilisant le framebuffer EFI-GOP ou VESA, fourni par le firmware UEFI ou le BIOS. Le but principal du driver est de permettre la sortie graphique dans les premiĂšres Ă©tapes du chargement, avant qu'il ne soit possible d'utiliser un driver DRM Ă  part entiĂšre. Le driver peut Ă©galement ĂȘtre utilisĂ© comme solution temporaire pour le matĂ©riel pour lequel il n'existe pas encore de drivers DRM natifs;
    • ajoutĂ© prise en charge de l’ordinateur tout-en-un Raspberry Pi 400;
    • ajout du driver dell-wmi-privacy pour prendre en charge les interrupteurs matĂ©riels de camĂ©ra et de microphone fournis dans les ordinateurs portables Dell;
    • pour les ordinateurs portables Lenovo ajoutĂ© interface WMI pour modifier les paramĂštres du BIOS via sysfs /sys/class/firmware-attributes/;
    • extension de la prise en charge des dispositifs avec interface USB4;
    • ajoutĂ© prise en charge des cartes son et des codecs AmLogic SM1 TOACODEC, Intel AlderLake-M, NXP i.MX8, NXP TFA1, TDF9897, Rockchip RK817, Qualcomm Quinary MI2 et Texas Instruments TAS2505. AmĂ©lioration de la prise en charge audio sur les ordinateurs portables HP et ASUS. AjoutĂ©s patches pour rĂ©duire les dĂ©lais avant le dĂ©marrage de la lecture audio sur les appareils dotĂ©s d'une interface USB.

Source – opennet.ru.

Source : linux.org.ru

Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS đŸ”„ Acheter un hĂ©bergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster