QEMU devrait passer de C à Rust

En 2018, le choix d’une langue plus sûre n’était pas clair. C ++ offrait des abstractions sûres sans moyen efficace d’interdire les fonctionnalités de langage non sécurisées. Go a également offert la sécurité, mais avec des préoccupations concernant les coûts d’exécution. Rust avait l’air prometteur mais peu de gens en avaient une expérience approfondie. En 2018, je n’ai pas pu argumenter avec confiance pour m’éloigner du C dans QEMU.

Maintenant, en 2020, la situation est plus claire. Les bogues de programmation C sont toujours la principale cause des CVE dans QEMU . Rust a mûri, son écosystème est en croissance et en bonne santé, et il existe des projets de virtualisation comme Crosvm , Firecracker et cloud-hypervisor qui prouvent que Rust est un langage efficace pour écrire des moniteurs de machine virtuelle (VMM). Dans la communauté QEMU, le travail de Paolo Bonzini et Sergio Lopez sur le code rust-vmm et vhost-user m’a inspiré à regarder de plus près pour m’éloigner de C.

Avons-nous besoin de changer de langage de programmation? La plupart des bogues de sécurité dans QEMU sont des bogues de programmation C. Ceci est facile à vérifier en parcourant les listes CVE. Bien que je n’ai examiné que les CVE, il semble probable que les bogues non liés à la sécurité soient aussi principalement des bogues de programmation C.

L’élimination des bogues de programmation C ne nécessite pas nécessairement de changer de langage de programmation. D’autres approches pour réduire les taux de bogues dans les logiciels comprennent: Règles de style de codage interdisant les fonctionnalités de langage non sécurisées. Construire des abstractions sûres et interdire les fonctionnalités de langage ou les API de bibliothèque non sécurisées. Vérificateurs statiques qui analysent le code source pour les bogues.Des désinfectants dynamiques qui exécutent des logiciels avec une instrumentation pour identifier les bogues.Test unitaire et fuzzing.

Le problème est que la communauté QEMU fait ces choses depuis des années mais de nouveaux bugs sont encore introduits malgré ces efforts. Il est certainement possible de consacrer plus d’énergie à ces efforts, mais les preuves montrent que les bogues continuent de se glisser. Il y a deux problèmes avec ces approches pour réduire les bogues. Premièrement, bien que ces approches aident à trouver les bogues existants, éliminer les classes de bogues afin qu’elles ne puissent pas exister en premier lieu est une approche plus forte. C’est difficile à faire avec C car le langage n’est pas sûr, ce qui fait peser le fardeau de la sécurité sur le programmeur.

Deuxièmement, une grande partie de la capacité d’écrire du code C sûr vient avec difficile à faire avec C car le langage n’est pas sûr, ce qui fait peser le fardeau de la sécurité sur le programmeur. Deuxièmement, une grande partie de la capacité d’écrire du code C sûr vient avec l’expérience. Les conventions, API, outils et processus personnalisés pour réduire les bogues sont un obstacle pour les contributeurs ponctuels ou les nouveaux arrivants. Cela rend la base de code inaccessible à moins que nous n’acceptions des normes inférieures pour certains contributeurs.

La qualité du code doit dépendre le moins possible de l’expérience, mais C est connu pour être un langage de programmation qui nécessite beaucoup de pratique avant de pouvoir écrire du code de qualité production. Pourquoi Rust? Les langages sûrs éliminent les bogues de sécurité de la mémoire (et d’autres classes comme les bogues de concurrence). Rust en a fait une priorité dans sa conception: Les fuites de mémoire et autres bogues de durée de vie sont évités au moment de la compilation par le vérificateur d’emprunt où le compilateur vérifie la propriété des données. Les débordements de tampon et autres corruptions de mémoire sont évités par la vérification des limites de compilation et d’exécution.

Les bogues de déférence de pointeur sont évités par l’absence de pointeurs NULL et de règles de propriété strictes. La mémoire non initialisée est empêchée car toutes les variables et tous les champs doivent être initialisés. Les programmes Rust peuvent encore «paniquer» au moment de l’exécution lorsque la sécurité ne peut pas être prouvée au moment de la compilation, mais cela n’entraîne pas un comportement indéfini comme on le voit dans les programmes C. Le programme abandonne simplement avec un retour en arrière. Les bogues qui auraient pu entraîner l’exécution de code arbitraire en C deviennent tout au plus des bogues de déni de service dans Rust. Cela réduit la gravité des bogues. En raison de cette conception de langage, la plupart des bogues de programmation C qui affligent QEMU aujourd’hui sont soit capturés par le compilateur, soit se transforment en une terminaison de programme sûre.

Il est raisonnable de s’attendre à ce que les CVE réduisent en nombre et en gravité lors du passage à Rust. Dans le même temps, Rust élimine le besoin de nombreuses mesures que la communauté QEMU a ajoutées à C car le langage de programmation Rust et son compilateur appliquent déjà la sécurité. Cela signifie que les nouveaux arrivants et les contributeurs ponctuels n’auront pas besoin d’une expérience spécifique à QEMU, pourront écrire plus facilement du code de qualité de production et pourront fusionner leur code plus rapidement. Cela signifie également que les réviseurs devront passer moins de temps à signaler les bogues de programmation C ou à demander des changements conformes à la façon de faire de QEMU. Cela dit, Rust a la réputation d’être un langage effrayant en raison du vérificateur d’emprunt.

La plupart des programmeurs n’ont pas pensé à la durée de vie et à la propriété des objets aussi systématiquement et explicitement que requis par Rust. Cela élève la barre pour apprendre le langage, mais je le vois de cette façon: apprendre Rust est humainement possible, écrire du code C sans bogue ne l’est pas. Comment changer le langage de programmation? Lorsque j’ai vérifié en 2018, QEMU comptait 1,5 million de lignes de code. Il a grandi depuis. Déplacer une grande base de code vers un nouveau langage de programmation est extrêmement difficile. Si les gens veulent convertir QEMU en Rust, ce serait génial, mais personnellement, je n’ai pas l’appétit de le faire car je pense que l’intégration sera compliquée, entraînera beaucoup de duplication et il y a trop de sous (der) code maintenu qui est difficile à convertir.

La raison pour laquelle j’écris cet article est que l’émulation de périphérique, la principale surface d’attaque de sécurité pour les VMM, peut être effectuée dans un programme séparé. Ce programme peut être écrit dans n’importe quelle langue et c’est là que Rust entre en jeu. Pour les périphériques vhost, il est possible d’écrire des backends de périphériques Rust aujourd’hui et j’espère que cela deviendra l’approche par défaut pour écrire de nouveaux périphériques. Pour les périphériques non-vhost, le projet vfio-user travaille sur une émulation de périphérique hors processus d’interface. Il sera également possible d’implémenter des appareils dans Rust.

Si vous implémentez un nouveau code d’émulation de périphérique, envisagez de le faire dans Rust! Conclusion La plupart des bogues de sécurité dans QEMU aujourd’hui sont des bogues de programmation C. Le passage à un langage de programmation plus sûr réduira considérablement les bogues de sécurité dans QEMU. Rust est maintenant suffisamment mature et prouvé pour être utilisé comme langage pour le code d’émulation de périphérique.

Merci à vhost-user et vfio-user utilisant Rust pour l’émulation de périphérique ne nécessite pas une grosse conversion de code QEMU, cela peut simplement être fait dans un programme séparé. De cette façon, les surfaces d’attaque peuvent être écrites dans Rust pour les rendre moins vulnérables aux bogues de sécurité à l’avenir.

Source