La version 1.81 du langage de programmation polyvalent Rust, initialement développé par Mozilla et désormais soutenu par l'organisation à but non lucratif Rust Foundation, a été publiée. Ce langage est axé sur la sécurité de la mémoire et offre des moyens d'atteindre un haut degré de parallélisme dans l'exécution des tâches, tout en évitant l'utilisation d'un ramasse-miettes et d'un runtime (le runtime se limite à une initialisation de base et à la gestion de la bibliothèque standard).
Les méthodes de gestion de la mémoire en Rust éliminent les erreurs lors de la manipulation des pointeurs et protègent contre les problèmes liés à la gestion bas niveau de la mémoire, tels que l'accès à une zone mémoire après sa libération, la déréférence de pointeurs nuls, le dépassement de tampon, etc. Pour faciliter la diffusion des bibliothèques, assurer la compilation et gérer les dépendances, un gestionnaire de paquets nommé Cargo est en développement. Un dépôt pour le déploiement des bibliothèques, crates.io, est également supporté.
La sécurité de la mémoire dans Rust est assurée au moment de la compilation grâce à la vérification des références, au suivi de la propriété des objets, à la prise en compte de la durée de vie des objets (portée) et à l'évaluation de l'accès mémoire pendant l'exécution du code. Rust offre également des outils pour se protéger contre les débordements d'entiers, exige l'initialisation obligatoire des valeurs des variables avant leur utilisation, gère mieux les erreurs dans la bibliothèque standard, applique le concept d'immuabilité (immutable) pour les références et les variables par défaut, et propose une forte typage statique pour minimiser les erreurs logiques.
Les principales nouveautés :
- Le trait core::error::Error a été stabilisé, définissant les descriptions d'erreurs renvoyées. Ce changement permet d'utiliser un trait Error unique dans diverses bibliothèques, quel que soit l'environnement, y compris dans des bibliothèques non liées à la bibliothèque standard, utilisant l'attribut «#![no_std]».
- Les fonctions de tri stables et instables de la bibliothèque standard ont été converties pour utiliser de nouveaux algorithmes, montrant une vitesse de traitement plus élevée et un temps de compilation réduit. Dans l'implémentation de ces nouveaux algorithmes de tri, la détection des traits Ord incorrectement définis a été assurée, avec un message d'erreur (panic) retourné dans ces cas au lieu de données regroupées de manière aléatoire.
- Un nouveau niveau de vérification «expect» («#[expect(lint)]») a été implémenté dans le linter, permettant de s'assurer que la vérification est effectuée et de renvoyer un avertissement si ce n'est pas le cas (en raison d'une erreur d'implémentation ou de la désactivation de la vérification). Par exemple, lors de la migration d'une base de code vers l'utilisation de la vérification undocumented_unsafe_blocks via Clippy, on peut spécifier «#[expect(clippy::undocumented_unsafe_blocks)]» afin de s'assurer que tous les blocs unsafe seront documentés durant la transition. Clippy a également introduit des vérifications clippy::allow_attributes et clippy::allow_attributes_without_reason, facilitant le remplacement des attributs «#[allow]» par «#[expect(lint)]».
- Il est désormais possible de documenter la raison de la modification des niveaux de vérification (lint), fournissant aux nouveaux développeurs des informations sur les raisons d'ajout de chaque vérification, affichées sous forme de message du compilateur. Par exemple : #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
- Une nouvelle série d'API a été stabilisée dans la catégorie des API stables, notamment des méthodes et des implémentations de traits stabilisées :
- core::error
- hint::assert_unchecked
- fs::exists
- AtomicBool::fetch_not
- Duration::abs_diff
- IoSlice::advance
- IoSlice::advance_slices
- IoSliceMut::advance
- IoSliceMut::advance_slices
- PanicHookInfo
- PanicInfo::message
- PanicMessage
Le mot-clé «const», qui détermine la possibilité d'utilisation dans n'importe quel contexte à la place des constantes, est utilisé dans les fonctions :
- char::from_u32_unchecked (fonction)
- char::from_u32_unchecked (méthode)
- CStr::count_bytes
- CStr::from_ptr
Le type std::panic::PanicInfo a été renommé en std::panic::PanicHookInfo (l'utilisation de l'ancien nom sera toujours supportée, mais à partir de la prochaine version, cela déclenchera un avertissement). Pendant ce temps, core::panic::PanicInfo restera tel quel, mais sera développé comme un type séparé. La séparation des types permettra d'implémenter en eux différentes méthodes spécifiques à l'exécution dans le contexte snd et no_std.
- La transition vers ABI C-unwind (‘extern «C-unwind»‘) a été complétée, se distinguant de l'ABI sans le suffixe «-unwind» (‘extern «C»‘) par la préservation du comportement sûr (safe), si le processus de «déballage» (unwinding), lancé lors d'une panne ou générant une exception de style C++, traverse la frontière ABI (par exemple, lorsque l'exception, survenant dans le code d'un langage de programmation, touche la pile liée à un code d'un autre langage lors du déballage). À partir de la version Rust 1.81, l'ABI ‘extern «C»‘ inclut la fermeture d'urgence lors d'un déballage non intercepté.
- Un troisième niveau de support a été mis en œuvre pour les plateformes i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Le troisième niveau implique un support de base, mais sans tests automatisés, publication de versions officielles, et vérification de la capacité de compilation du code.
- Un deuxième niveau de support a été mis en œuvre pour les plateformes cibles loongarch64-unknown-linux-musl et arm64ec-pc-windows-msvc. Le deuxième niveau de support garantit la compilation.
- Un ensemble complet d'outils et un profileur ont été fournis pour les systèmes Linux sur la plateforme LoongArch.
- Une vulnérabilité (CVE-2024-43402) a été corrigée dans std::process::Command, apparaissant uniquement sur la plateforme Windows et éliminant un contournement d'exploitation d'une vulnérabilité précédemment corrigée, BatBadBut, liée à la gestion des caractères spéciaux lors de l'utilisation des appels Command::arg et Command::args, conçus pour transmettre directement des arguments à un processus sans traitement par l'interpréteur de commandes. En réalité, lors de l'exécution de scripts bat et cmd, le processus cmd.exe était lancé, possédant sa propre logique de séparation des arguments. Le contournement de protection est basé sur le fait que Windows supprime les espaces et les points initiaux dans les chemins, c'est-à-dire qu'un fichier avec l'extension « .bat. . » est traité comme « .bat ».
De plus, il est à noter que Wedson Almeida Filho a quitté son poste de responsable du projet Rust for Linux, qui s'occupe de l'intégration des outils de développement en langage Rust dans le noyau Linux. Après le départ de Wedson, le projet a encore deux responsables : Miguel Ojeda, auteur et développeur principal du projet Rust-for-Linux, et Alex Gaynor, ancien directeur de la Python Software Foundation, qui s'est tourné vers la promotion de Rust. Le responsable sortant, qui a rejoint le projet il y a 4 ans, est employé par Microsoft et est l'auteur d'un pilote expérimental avec une implémentation du système de fichiers EXT2, écrit en langage Rust. Dernièrement, le travail d'Almeida était axé sur la création d'outils pour le développement de systèmes de fichiers en Rust. Cette année, Almeida a contribué 17 commits au dépôt Rust-for-Linux (contre 53 pour Miguel Ojeda).
Comme raison de son départ, il cite un manque de force et d'enthousiasme pour répondre à certaines absurdités non techniques. Selon Almeida, les développeurs doivent consacrer beaucoup d'énergie à des disputes sur des questions insignifiantes qui annihilent un objectif global plus important. Almeida continue de croire que l'avenir des noyaux réside dans l'utilisation de langages qui garantissent une gestion sécurisée de la mémoire ; si la communauté des développeurs Linux ne comprend pas cela, Linux sera remplacé par un autre noyau, comme cela s'est produit avec Unix par le passé.
Les partisans du projet Rust-for-Linux se sont heurtés à la résistance de vieux développeurs du noyau bien établis, qui ne voient pas l'intérêt d'apprendre un nouveau langage. Dans sa lettre de démission, Almeida cite en exemple une discussion qui a eu lieu lors de sa présentation avec Kent Overstreet à la conférence « Linux Storage, Filesystem, Memory-Management, and BPF Summit », consacrée à l'utilisation de Rust pour le développement de systèmes de fichiers. Ted Ts'o, auteur des systèmes de fichiers ext2/ext3/ext4, a critiqué l'initiative Rust-for-Linux en la comparant à une tentative de forcer tout le monde à adopter la religion Rust.
En réponse à l'intention d'Almeida de créer un wrapper autour des interfaces de système de fichiers écrites en C pour les utiliser dans le code Rust, Ted Ts'o a souligné qu'un tel wrapper entraînerait inévitablement des problèmes, car tout changement des interfaces C et tout refactoring nécessiterait une modification du wrapper pour Rust, et il ne veut pas assumer la responsabilité de corriger les problèmes qui surviendraient dans le code Rust et de suivre l'état du wrapper Rust. Le code en C évolue constamment et si des changements perturbent le fonctionnement du wrapper pour Rust, cela affecterait également toutes les systèmes de fichiers liés à ce wrapper.
Ted estime également que, dans un avenir proche, le wrapper pour Rust restera secondaire et que les problèmes dans les bindings ne seront une préoccupation que pour les développeurs de Rust-for-Linux, et non pour la communauté des développeurs de systèmes de fichiers du noyau. Il a été signalé que tous les développeurs ne vont pas apprendre Rust et donc, après avoir effectué des modifications qui impactent d'autres codes, ils pourront uniquement mettre à jour le code dépendant en C, mais ne pourront pas corriger les wrappers Rust car ils ne connaissent pas Rust. James Bottomley, qui maintient la sous-système SCSI, a également rejoint la discussion en disant que plus la sémantique est codée dans les wrappers, plus ils deviennent fragiles en termes de synchronisation.
En attendant, Google, qui a réécrit l'année dernière le firmware pvmfm en Rust, utilisé dans des machines virtuelles, lancé sur la plateforme Android, a partagé son expérience de l'intégration progressive du code en Rust dans des firmwares existants, initialement écrits en C ou C++. Il a été démontré comment il est possible d'améliorer considérablement la sécurité des firmwares en créant des composants de remplacement identiques en fonctionnalité, écrits en Rust. L'accent est mis sur l'utilisation de Rust pour le nouveau code et le code effectuant des fonctions critiques sur le plan de la sécurité (par exemple, le code de traitement des données externes provenant de sources non fiables). Pour intégrer le code en Rust et en C, il est suggéré d'utiliser des couches d'abstraction (shim) qui traduisent les appels entre les API Rust et C (l'API C est exportée pour être utilisée dans le code Rust et vice versa), permettant une réécriture progressive des éléments de l'API en Rust.
Source : opennet.ru
