If Memory Safety is The Goal Rust is Not The Solution

SYNTHÈSE STRUCTURÉE

La prétention à la sécurité mémoire de Rust remise en cause

L’intervenant, tout en mettant de côté ses critiques personnelles sur Rust, s’attaque à son argument de vente principal : la sécurité mémoire. Il affirme que si cet aspect était vraiment prioritaire, Rust ne serait pas le choix logique dans sa forme actuelle. Son raisonnement est que les projets Rust significatifs reposent massivement sur des appels unsafe, ce qui compromet leur sécurité fondamentale.

L’omniprésence du mot-clé unsafe dans les grands projets

Pour étayer son propos, il cite des exemples concrets comme l’environnement de bureau COSMIC de System76 ou les utilitaires coreutils réécrits en Rust (uutils). Il constate qu’en les examinant, on découvre “une vague déferlante du mot unsafe”. Cela permet d’exécuter des appels système non sécurisés depuis du code Rust théoriquement sûr, rendant le projet final non sécurisé. “Effectivement, la capacité à exécuter des appels système, des appels système non sécurisés en mémoire depuis l’intérieur du Rust sécurisé en mémoire… le résultat est fondamentalement des projets non sécurisés en mémoire.”

Phil C : une approche alternative pour sécuriser l’existant

Face à ce constat, il présente Phil C comme une solution plus pragmatique. Il s’agit d’un compilateur “fanatiquement compatible” pour le C et le C++ qui rend le code mémoire-sécurisé sans modifications significatives. L’idée est de protéger les décennies d’investissement dans les logiciels existants plutôt que de tout réécrire de zéro. “Si le but est la sécurité mémoire, nous voulons rendre autant de code que possible sécurisé en mémoire, et rapidement.”

Une démonstration technique comparative

Le cœur de l’argumentation est une démonstration vidéo du développeur de Phil C. Elle compare un programme bugué (passant une longueur incorrecte à un appel système) écrit en Rust et en C. En Rust, l’utilisation obligatoire de unsafe pour l’appel système permet au bogue de passer inaperçu et d’exfiltrer de la mémoire. Compilé avec Phil C, le même programme en C voit l’erreur immédiatement détectée et bloquée. La conclusion du développeur est sans appel : “Phil C est plus sûr que Rust.”

Les réécritures en Rust : des objectifs autres que la sécurité ?

L’intervenant questionne les motivations réelles derrière les réécritures en Rust, comme celles des coreutils par Ubuntu. Il note qu’elles sont souvent buguées car elles perdent des décennies de tests et de corrections de cas limites. Surtout, il suggère que si la sécurité mémoire était le vrai but, on utiliserait Phil C pour recompiler le code existant et éprouvé. Il émet l’hypothèse que d’autres facteurs entrent en jeu, comme “une combinaison de fanatisme religieux [autour de Rust] avec le désir de se débarrasser du code sous licence GPL” au profit de licences plus permissives comme la MIT.

La promotion du Lunduke Journal

La dernière partie de la vidéo est une longue promotion pour le Lunduke Journal. L’animateur remercie ses abonnés, annonce des chiffres de croissance impressionnants (19 millions de vues en mars) et explique qu’il ne proposera plus de promotions pour les abonnements à vie, ceux-ci rencontrant un succès inattendu. Il met en avant l’indépendance éditoriale du journal, financé uniquement par son public.

CONCEPTS CLÉS

• Sécurité mémoire (Memory Safety) : Propriété d’un langage ou d’un environnement d’exécution qui empêche des classes de bugs comme les débordements de buffer ou les accès à de la mémoire libérée, sources de nombreuses vulnérabilités logicielles.
• Mot-clé unsafe (Rust) : Bloc de code dans lequel le programmeur prend la responsabilité de garantir la sécurité mémoire, contournant ainsi les garanties du compilateur Rust. Nécessaire pour interagir avec du code non-Rust ou le matériel.
• Phil C : Un compilateur pour le C et le C++ qui vise à fournir une sécurité mémoire complète sans changer le code source, en utilisant notamment un ramasse-miettes (garbage collector).
• FFI (Foreign Function Interface) : Mécanisme permettant à un langage de programmation d’appeler des routines ou d’utiliser des services écrits dans un autre langage (par exemple, Rust appelant des bibliothèques C).
• uutils : Un projet visant à réécrire les utilitaires de base GNU (coreutils comme ls, cp) en Rust.

CONCLUSION

Le message principal est un plaidoyer pour une évaluation pragmatique des solutions de sécurité mémoire. L’intervenant argue que l’enthousiasme autour de Rust comme solution miracle est techniquement imparfait à cause de sa dépendance aux blocs unsafe, et que l’approche de Phil C – sécuriser la montagne de code C/C++ existant – est plus rationnelle si l’objectif est réellement d’améliorer la sécurité à grande échelle. Cette analyse importe car elle remet en question une narrative dominante dans l’industrie et met en lumière un outil alternatif, tout en soulignant l’importance de distinguer les objectifs techniques réels des tendances ou des motivations communautaires.