Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

Cet article présente les pièges spécifiques à l'implémentation de machines virtuelles sur l'architecture CHERI, identifiés lors du portage de CRuby, qui découlent de comportements non définis en C supposés valides sur les architectures traditionnelles mais incompatibles avec le modèle de sécurité mémoire de CHERI, tout en proposant des solutions de contournement validées.

L'essentiel

🛡️ Le Grand Remodelage : Quand le langage Ruby rencontre le "Super-Héros" CHERI

Imaginez que vous avez un vieux château (le langage de programmation Ruby et son moteur, la Machine Virtuelle ou VM). Ce château fonctionne depuis des décennies, mais il a des portes faibles, des murs fissurés et des passages secrets que n'importe qui peut emprunter pour voler ou détruire des choses. C'est ce qu'on appelle les failles de sécurité mémoire.

Pour réparer ce château, les chercheurs ont conçu un nouveau système de sécurité ultra-puissant appelé CHERI. Au lieu d'avoir de simples clés (les pointeurs classiques), CHERI donne à chaque objet une carte d'identité magique (une "capacité"). Cette carte ne dit pas seulement "où" se trouve l'objet, elle précise aussi "jusqu'où" vous pouvez aller et "ce que vous avez le droit de faire" (lire, écrire, exécuter). Si vous essayez d'ouvrir une porte avec une carte qui ne correspond pas exactement à la zone, le système vous arrête immédiatement.

Le problème ? Le château Ruby a été construit par des architectes qui pensaient que les clés étaient simples. Ils ont fait des suppositions sur la façon dont les choses fonctionnent, des suppositions qui sont fausses avec les nouvelles cartes d'identité de CHERI.

Ce papier raconte l'histoire de l'équipe qui a dû rénover le château Ruby pour qu'il fonctionne avec ce nouveau système de sécurité, et les pièges bizarres qu'ils ont rencontrés.

---

🕵️‍♂️ Les 6 Pièges (et les analogies pour les comprendre)

Les chercheurs ont découvert six types de problèmes majeurs. Voici comment ils les expliquent avec des métaphores :

1. Le Piège de la "Carte Trop Petite" (Pointeurs dérivés invalides)

• Le problème : Imaginez que vous avez une carte d'accès à tout l'étage du château (la pile d'exécution). Vous en faites une copie pour aller dans une seule pièce (une variable locale). La copie est valide, mais elle ne vous autorise qu'à entrer dans cette pièce.
• L'erreur : Le vieux Ruby prenait cette copie restreinte et disait : "Tiens, je vais l'utiliser pour parcourir tout l'étage !"
• La conséquence : Le système de sécurité CHERI crie : "Arrête ! Ta carte ne couvre que cette pièce, tu ne peux pas aller ailleurs !" et bloque tout.
• La solution : Garder toujours la "Super-Carte" (celle qui couvre tout l'étage) en réserve et ne jamais l'oublier, même quand on en a besoin pour des petites tâches.

2. Le Piège du "Faux Visage" (Déréférencement de pointeurs ambigus)

• Le problème : Le système de sécurité (Garbage Collector) doit trier les objets. Il regarde les chiffres sur la table et se dit : "Celui-ci ressemble à une clé, je vais l'essayer."
• L'erreur : Parfois, un simple nombre (un entier) a exactement la même apparence qu'une clé. Sur les vieux systèmes, on l'essayait et ça marchait (ou ça plantait gentiment). Sur CHERI, si ce nombre n'a pas la "carte d'identité" valide (le tag), le système le rejette violemment.
• La solution : Au lieu de regarder juste la forme du nombre, on vérifie sa carte d'identité. Si le tag est manquant, on sait tout de suite que ce n'est pas une vraie clé. C'est même plus rapide !

3. Le Piège du "Tapis Rouge qui Change" (Réallocation sur place)

• Le problème : Imaginez que vous avez un tapis (un bloc de mémoire) et que vous voulez le rallonger pour mettre plus de meubles.
• L'erreur : Le vieux Ruby disait : "Je rallonge le tapis, mais je garde la même étiquette sur le coin du tapis."
• La conséquence : Sur CHERI, quand on rallonge le tapis, l'étiquette (la capacité) change pour refléter la nouvelle taille. Si le vieux Ruby continue d'utiliser l'ancienne étiquette (qui dit "taille courte") pour écrire sur la partie rallongée, le système bloque : "Hé ! Tu écris en dehors de tes limites !"
• La solution : Ne jamais supposer que l'adresse reste la même après un agrandissement. Il faut toujours mettre à jour l'étiquette avec la nouvelle version.

4. Le Piège des "Bits Fantômes" (Utilisation des bits de remplissage)

• Le problème : Les nouvelles cartes d'identité (les capacités) sont plus grosses que les anciennes clés. Pour les faire entrer dans les vieux tiroirs, on a ajouté des espaces vides (des bits de remplissage) qui contiennent des informations secrètes (les métadonnées).
• L'erreur : Le vieux Ruby prenait une carte, la transformait en nombre, et jouait avec tous les bits, y compris ceux qui contiennent les secrets de sécurité.
• La conséquence : En modifiant ces bits secrets, on corrompt la carte d'identité. CHERI ne comprend plus rien et plante.
• La solution : Utiliser des boîtes (types entiers) qui n'ont pas de secrets cachés à l'intérieur, pour ne toucher qu'aux données utiles.

5. Le Piège de la "Clé Scellée" (Modification de capacités temporaires)

• Le problème : Certaines clés sont "scellées" (comme un cachet de cire sur une lettre). On ne peut pas les modifier, sinon le cachet casse. C'est le cas des adresses de retour des fonctions.
• L'erreur : Le compilateur CHERI est très intelligent. Parfois, il crée une "copie temporaire" d'une clé pour faire un calcul mathématique. Si la clé originale était scellée, cette copie temporaire essaie de modifier le cachet, ce qui est interdit.
• La conséquence : Explosion de sécurité (faute de capacité scellée).
• La solution : Dire au compilateur : "Ne fais pas de copie temporaire, traite ça comme un simple nombre brut."

6. Le Piège du "Changement de Costume" (Arithmétique sur des types non-capables)

• Le problème : En programmation, on fait souvent des calculs sur des adresses en les transformant en nombres, puis on les retransforme en adresses.
• L'erreur : Le vieux Ruby utilisait des "nombres génériques" (comme size_t) pour faire ces calculs. Mais sur CHERI, seul un "nombre spécial" (uintptr_t) sait comment garder la carte d'identité intacte pendant le calcul.
• La conséquence : Quand on retransforme le nombre en adresse, la carte d'identité est perdue ou corrompue. La nouvelle clé ne fonctionne plus.
• La solution : Utiliser uniquement le "nombre spécial" (uintptr_t) pour tous les calculs d'adresses.

---

📉 Est-ce que ça ralentit tout ?

C'est la grande question : si on ajoute toutes ces règles de sécurité, est-ce que le château Ruby va devenir une tortue ?

Les chercheurs ont fait des tests. Résultat : Non, pas vraiment !

• La plupart des tâches vont à la même vitesse (98% de la vitesse originale).
• Il y a quelques exceptions (comme la gestion des "fibres", un type de multitâche), où c'est un peu plus lent, mais c'est acceptable.
• Le plus important : en corrigeant ces bugs, le système devient beaucoup plus sûr, et parfois même plus précis dans sa gestion de la mémoire.

🏁 Conclusion

Ce papier nous apprend une leçon précieuse : On ne peut pas simplement copier-coller du vieux code sur une nouvelle architecture de sécurité.

Les développeurs de machines virtuelles (comme celle de Ruby) ont l'habitude de tricher un peu avec les règles du langage C pour aller plus vite. CHERI, lui, ne tolère aucune triche. Pour construire un château sûr avec CHERI, il faut :

1. Arrêter de faire des suppositions sur la façon dont la mémoire fonctionne.
2. Respecter strictement les règles des cartes d'identité (capacités).
3. Utiliser les bons outils (types de données) pour chaque tâche.

C'est un travail de rénovation difficile, mais c'est la seule façon de construire des logiciels qui résistent vraiment aux pirates de demain.

Résumé technique

Voici un résumé technique détaillé de l'article « Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby » (Pièges dans l'implémentation de machines virtuelles sur CHERI : Leçons tirées du portage de CRuby), rédigé en français.

1. Problématique

L'architecture CHERI (Capability Hardware Enhanced RISC Instructions) vise à résoudre les problèmes de sécurité mémoire en remplaçant les pointeurs traditionnels par des capacités (capabilities). Ces capacités sont des pointeurs « gras » (fat pointers) contenant des métadonnées (bornes, permissions, tag de validité) qui garantissent la sécurité spatiale et temporelle.

Cependant, le portage de Machines Virtuelles (VM) complexes, comme celles des langages de programmation (ex: CRuby, MicroPython), vers CHERI s'avère être une tâche non triviale. Les développeurs de VMs reposent souvent sur des comportements non définis (undefined behaviors) du langage C, qui sont valides sur les architectures conventionnelles mais deviennent des sources d'erreurs critiques sur CHERI.

Les principaux défis identifiés sont :

• Les hypothèses de sécurité implicites des VMs (ex: Garbage Collectors conservateurs) qui entrent en conflit avec le modèle de sécurité strict de CHERI.
• L'absence de guides de programmation spécifiques aux VMs dans la documentation existante de CHERI.
• La difficulté à distinguer les erreurs de portage général des pièges spécifiques à l'implémentation des VMs.

2. Méthodologie

Les auteurs ont adopté une approche empirique combinant un cas d'étude pratique et une revue de la littérature :

1. Cas d'étude (Portage de CRuby) :

   • Ils ont porté CRuby (l'implémentation de référence de Ruby, entièrement écrite en C) sur l'architecture CHERI-RISC-V (mode purecap).
   • Le périmètre incluait le système d'exécution et l'interpréteur, excluant le compilateur JIT et l'interface FFI (Foreign Function Interface).
   • Ils ont compilé le code, corrigé les erreurs de compilation et de test, et analysé les échecs.
   • Résultat initial : 29 609 tests réussis sur 34 046 (le nombre de lignes modifiées est faible, environ 0,077 % du codebase, mais les corrections sont critiques).

2. Analyse comparative :

   • Ils ont comparé leurs découvertes avec trois travaux antérieurs de portage : MicroPython, JavaScriptCore et le compilateur Rust.
   • Ils ont catégorisé les problèmes rencontrés en fonction de leurs causes racines (comportements du C, hypothèses d'architecture, etc.).

3. Évaluation des contournements :

   • Pour chaque catégorie de problème, ils ont proposé des solutions (workarounds) et évalué leur impact sur la sécurité et les performances via des benchmarks.

3. Contributions Clés : Les Catégories de Pièges

L'article identifie et classe six catégories principales de pièges spécifiques aux VMs sur CHERI :

A. Pointeurs dérivés invalides (Invalid Derived Pointer)

• Problème : Les VMs dérivent souvent des pointeurs à partir d'autres pointeurs créés pour un but différent (ex: obtenir l'adresse de la pile via une variable locale pour le balayage de pile). Sur CHERI, le pointeur dérivé hérite des bornes strictes de l'original, ce qui provoque des fautes de bornes (bounds faults) lors de l'accès à des zones adjacentes.
• Solution : Maintenir un « super-capacité » (super capability) avec des bornes larges couvrant toute la région mémoire nécessaire (ex: toute la pile) et dériver les pointeurs temporaires de celle-ci.

B. Déférencement de pointeurs ambigus (Dereferencing Ambiguous Pointers)

• Problème : Les GC conservateurs scannent la pile pour trouver des valeurs ressemblant à des pointeurs (motifs de bits). Sur CHERI, convertir un entier en capacité sans tag de validité entraîne une faute de tag. Un entier peut avoir le même motif de bits qu'un pointeur valide mais ne pas l'être.
• Solution : Vérifier le tag de validité de la capacité avant de la déférencer, au lieu de se fier uniquement au motif de bits. Cela permet même d'optimiser le GC en évitant de marquer des objets morts qui ne sont que des entiers ressemblant à des pointeurs.

C. Réallocation sur place (In-Place Reallocation)

• Problème : Les allocateurs personnalisés de VMs supposent souvent que realloc conserve le même pointeur (même adresse) même si la taille change. Sur CHERI, une réallocation peut retourner une capacité avec des bornes différentes. Utiliser l'ancien pointeur pour accéder à la nouvelle zone étendue provoque une faute de bornes.
• Solution : Ne jamais dépendre de la réallocation sur place. Toujours utiliser le pointeur retourné par l'allocation et mettre à jour toutes les références.

D. Utilisation des bits de remplissage (Using Padding Bits)

• Problème : Les VMs utilisent souvent des opérations bitiques sur des types entiers larges (ex: uintptr_t) pour stocker des métadonnées ou des drapeaux. Sur CHERI, uintptr_t est une capacité de 128 bits (64 bits d'adresse + 64 bits de métadonnées). Les 64 bits supérieurs sont des bits de remplissage (padding) pour les valeurs entières. Les opérations de décalage (shift) ou de masquage sur ces bits peuvent échouer ou produire des résultats indéfinis.
• Solution : Utiliser des types entiers de largeur exacte (ex: uint64_t) pour les opérations bitiques, et non uintptr_t.

E. Modification de capacités temporaires introduites par le compilateur

• Problème : Les adresses de retour (sealed capabilities) sont scellées. Le compilateur CHERI peut générer du code pour créer des capacités temporaires lors d'opérations binaires sur uintptr_t. Si l'opérande est une capacité scellée, cette tentative de modification provoque une faute de capacité scellée (sealed fault).
• Solution : Cast explicite des opérandes uintptr_t vers des types non-capacité (ex: uint64_t) avant l'opération arithmétique ou logique, si le résultat n'a pas besoin d'être un pointeur valide.

F. Arithmétique de pointeurs sur des types non-capacité

• Problème : Les VMs utilisent souvent l'arithmétique de pointeurs via des types comme size_t (ex: pour l'héritage de classes simulé en C). Sur CHERI, size_t ne garantit pas la récupération des métadonnées de la capacité. Le résultat est une capacité invalide.
• Solution : Utiliser strictement uintptr_t pour toute arithmétique de pointeurs afin de préserver les métadonnées.

4. Résultats et Évaluation

• Fonctionnalité : Le portage de CRuby a permis de passer la majorité des tests (29 609/34 046). Les échecs restants sont principalement dus à des dépendances externes (libyaml) ou à des cas non encore résolus, mais non à des défauts fondamentaux de l'approche.
• Performance : Une évaluation comparative sur un CPU x86 (pour simuler l'environnement de test) a montré que la version portée de Ruby atteint en moyenne 98,2 % du débit de la version originale.
  • La plupart des benchmarks sont quasi-identiques.
  • Quelques outliers (liés aux fibers) montrent une baisse de performance significative (jusqu'à 10x) due à l'utilisation d'une implémentation générique au lieu d'une version optimisée en assembleur x86.
  • Les contournements (workarounds) n'ont pas introduit de surcharge de performance notable ; certains, comme l'utilisation des tags de validité dans le GC, pourraient même améliorer les performances en réduisant le travail inutile.

5. Signification et Impact

Cet article apporte une contribution majeure à la communauté de la sécurité et du développement de langages :

1. Guide pratique pour les VMs : Il comble le vide entre les guides de programmation CHERI généraux et les besoins spécifiques des systèmes d'exécution de langages.
2. Sécurité accrue : En forçant les développeurs à abandonner les comportements non définis du C, le portage vers CHERI rend les VMs intrinsèquement plus robustes contre les vulnérabilités mémoire.
3. Optimisation du GC : L'utilisation des tags de validité permet d'envisager des Garbage Collectors plus précis (sans besoin de pinning des objets) et plus efficaces.
4. Leçons transférables : Les catégories de problèmes identifiées s'appliquent non seulement à CRuby, mais aussi à d'autres VMs (JavaScriptCore, MicroPython) et à d'autres systèmes complexes portés sur CHERI.

En conclusion, bien que le portage de VMs sur CHERI nécessite de réviser des idiomes de programmation C profondément ancrés, les solutions proposées sont réalisables avec un impact minimal sur les performances et un gain significatif en matière de sécurité.