Les LLM peinent avec unsafe Rust : six mois de tests ont révélé des erreurs critiques
Pendant six mois, l’auteur a fait écrire du code unsafe Rust à des LLM dans des projets réels et a analysé les résultats avec Miri. Les modèles se trompent de f
L'auteur a demandé à LLM d'écrire du code unsafe Rust dans des projets en production pendant six mois et a vérifié chaque bloc avec Miri et des sanitizers. Le résultat était décevant : les modèles faisaient les mêmes erreurs de manière prévisible et constante.
Sept catégories d'erreurs LLM dans unsafe Rust
Les modèles font systématiquement les mêmes erreurs aux mêmes endroits :
- Aliasing — violation de la règle des références non chevauchantes
- Provenance — tentatives d'utiliser des pointeurs obtenus de manière incorrecte
- Layout en alloc/dealloc — désalignement de taille/alignement lors de l'allocation et la désallocation
- ManuallyDrop — oublient d'appeler drop ou accèdent à l'objet après drop
- Race conditions dans les callbacks FFI — conditions de course lors de l'appel de fonctions C à partir de threads
- Send/Sync manuels — implémentent incorrectement les traits de sécurité des threads
- Mémoire Uninit — traitent les données non initialisées comme initialisées
Pourquoi Miri a révélé les problèmes
Miri est un interpréteur Rust qui suit le comportement indéfini. Lorsque LLM génère du code avec des violations subtiles à première vue (par exemple, un pointeur temporaire avec une provenance incorrecte), le compilateur régulier les manque, mais Miri les détecte. Sous les sanitizers (AddressSanitizer, ThreadSanitizer), les conditions de course et les use-after-free ont été découverts, ce qui peut ne pas apparaître dans les tests réguliers.
«
Chaque catégorie est accompagnée d'un exemple minimal et d'une correction » — l'auteur montre qu'il ne s'agit pas seulement d'observations, mais de modèles d'erreurs reproductibles.
Ce que cela signifie
Les LLM ne sont pas encore prêts à écrire unsafe Rust sans supervision humaine. Ils génèrent bien la syntaxe et la logique générale, mais font systématiquement des erreurs en gestion mémoire et multithreading. Pour le code critique (logiciels système, bibliothèques système), l'unsafe Rust des modèles doit être vérifié avec Miri.