Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

Dieser Beitrag analysiert anhand des Portings von CRuby auf CHERI spezifische Fallstricke bei der Implementierung von Virtual Machines, die durch die Kollision von C-Programmierungsideen mit dem strengen CHERI-Sicherheitsmodell entstehen, und stellt bewährte Lösungen vor.

Das Wesentliche

Hier ist eine einfache, bildhafte Erklärung der wissenschaftlichen Arbeit „Pitfalls in VM Implementation on CHERI" auf Deutsch.

Die große Idee: Ein unsichtbarer Sicherheitsgürtel

Stellen Sie sich vor, ein Computer ist wie ein riesiges, chaotisches Lagerhaus. In einem normalen Computer sind Zeiger (Pointer) wie einfache Zettel, auf denen nur eine Adresse steht: „Geh zu Regal 5, Fach 3". Das Problem ist: Jeder kann diesen Zettel lesen, ändern oder fälschen. Wenn ein Programm einen Zettel falsch hält, greift es vielleicht auf einen Bereich zu, in dem es nichts zu suchen hat – das führt zu Sicherheitslücken und Abstürzen.

CHERI ist wie ein revolutionäres neues System für dieses Lagerhaus. Statt eines einfachen Zettels gibt es jetzt einen Sicherheitsausweis (eine „Capability"). Dieser Ausweis enthält nicht nur die Adresse, sondern auch:

• Erlaubnisse: Darf ich hier nur lesen oder auch schreiben?
• Grenzen: Darf ich nur in Fach 3 schauen oder auch in Fach 4?
• Echtheitsprüfung: Ist dieser Ausweis echt oder gefälscht?

Wenn jemand versucht, ohne Erlaubnis in ein Fach zu greifen oder über die Grenzen hinaus zu schauen, schreit das System sofort „Stopp!" und blockiert den Zugriff. Das ist super sicher!

Das Problem: Der alte Schlüssel passt nicht ins neue Schloss

Die Autoren dieser Arbeit haben versucht, CRuby (die Standard-Software, die die Programmiersprache Ruby antreibt) auf dieses neue CHERI-System zu übertragen. CRuby ist wie ein riesiger, komplexer Maschinenpark, der in der Sprache C gebaut wurde.

Das Problem war: Die Entwickler von CRuby haben über Jahrzehnte viele „Tricks" benutzt, die auf dem alten System (dem normalen Lagerhaus) super funktionierten, aber auf dem neuen CHERI-System katastrophal scheitern.

Man kann sich das so vorstellen:

• Der alte Trick: Ein Mechaniker nimmt einen Schraubenschlüssel (einen Zeiger), dreht ihn um, nutzt ihn als Hammer und dann wieder als Schraubenschlüssel. Auf dem alten System ging das, weil alles aus Metall war.
• Das neue System: Auf CHERI ist der Schraubenschlüssel ein hochpräzises, elektronisches Werkzeug. Wenn man ihn als Hammer benutzt, löst er einen Alarm aus, weil er nicht für Hammerschläge „autorisiert" ist.

Die Forscher haben herausgefunden, wo genau diese „Alarmschreie" in CRuby passiert sind, und haben Lösungen gefunden. Hier sind die wichtigsten Fallen (Pitfalls) und ihre Lösungen, erklärt mit Analogien:

1. Die „Schatzsuche" auf dem falschen Weg (Grenzen verletzen)

• Das Szenario: Der Garbage Collector (ein Aufräumroboter) muss den ganzen Stapel (Stack) durchsuchen, um zu sehen, welche Dinge noch wichtig sind. Er nimmt einen Zeiger vom obersten Punkt und sagt: „Ich gehe jetzt Schritt für Schritt nach unten."
• Der Fehler: Auf dem alten System war das kein Problem. Auf CHERI hat dieser Zeiger aber eine „Sichtweite" (Bounds), die nur dieses eine Fach umfasst. Wenn der Roboter einen Schritt macht, ist er außerhalb seiner Sichtweite und wird gestoppt.
• Die Lösung: Man braucht einen „Meister-Schlüssel", der den gesamten Stapel abdeckt. Vom Meister-Schlüssel aus darf man dann kleinere Schlüssel ableiten, die immer noch sicher sind.

2. Die „Verwechslung" von Zahlen und Adressen

• Das Szenario: Der Aufräumroboter schaut sich Zahlen an und denkt: „Das sieht aus wie eine Adresse, also gehe ich da hin." Manchmal sind das aber nur zufällige Zahlen, die wie Adressen aussehen.
• Der Fehler: Auf dem alten System hat der Roboter einfach hingeschaut. Auf CHERI hat jede echte Adresse einen unsichtbaren „Sicherheitsstempel". Wenn der Roboter eine zufällige Zahl nimmt und versucht, sie als Adresse zu nutzen, fehlt der Stempel. Der Computer sagt: „Das ist kein echter Ausweis!" und blockiert.
• Die Lösung: Statt nur zu raten („Sieht das aus wie ein Ausweis?"), prüft der Roboter jetzt direkt den unsichtbaren Stempel. Ist er da? Gut. Ist er nicht da? Ignorieren. Das ist sogar schneller und sicherer!

3. Der „Erweiterungs-Trick" (Speicher neu verteilen)

• Das Szenario: Ein Programm braucht mehr Platz für Daten. Es sagt zum Speicher: „Vergrößere diesen Bereich, aber behalte die alte Adresse bei."
• Der Fehler: Auf CHERI kann es sein, dass der Speicher zwar an derselben Stelle bleibt, aber die „Grenzen" (Bounds) des Ausweises sich ändern. Wenn das Programm aber noch den alten Ausweis mit den alten Grenzen benutzt, um in den neuen, größeren Bereich zu schreiben, wird es blockiert.
• Die Lösung: Man muss sofort den neuen Ausweis nehmen, sobald der Speicher erweitert wurde. Man darf sich nicht auf den alten verlassen.

4. Die „geheime Bits"-Falle

• Das Szenario: Programmierer packen oft kleine Informationen (wie Status-Flags) in die „leeren" Bits einer großen Zahl, um Platz zu sparen.
• Der Fehler: Auf CHERI sind die oberen Bits einer Zahl nicht leer, sondern enthalten wichtige Metadaten (wie die Grenzen). Wenn das Programm diese Bits manipuliert, zerstört es versehentlich die Sicherheitsdaten des Ausweises.
• Die Lösung: Verwende für solche Tricks nur Zahlen, die genau so groß sind, wie sie sein müssen (z. B. 64-Bit-Zahlen), damit keine „Sicherheits-Bits" mitgemischt werden.

5. Der „versteckte" Alarm (Versiegelte Schlüssel)

• Das Szenario: Manche Schlüssel (z. B. für Rückkehradressen in Funktionen) sind „versiegelt". Sie dürfen nicht verändert werden, um Manipulationen zu verhindern.
• Der Fehler: Der Compiler von CHERI macht manchmal automatisch aus Zahlen wieder Ausweise. Wenn das Programm versucht, eine Zahl zu berechnen, die eigentlich ein versiegelter Ausweis ist, versucht der Compiler, diesen Ausweis zu „reparieren" oder zu ändern. Das löst einen Alarm aus, weil versiegelte Ausweise unveränderlich sein müssen.
• Die Lösung: Man muss dem Computer explizit sagen: „Behandle das hier nur als reine Zahl, nicht als Ausweis", bevor man rechnet.

Das Ergebnis: Ein sicherer, aber etwas schwererer Rucksack

Die Forscher haben CRuby so umgebaut, dass es auf CHERI läuft.

• Ergebnis: Das Programm läuft fast genauso schnell wie das Original (etwa 98 % der Geschwindigkeit).
• Der Preis: Es ist etwas mehr Arbeit für die Entwickler, diese „Sicherheitsregeln" einzuhalten. Aber im Gegenzug ist das System viel robuster gegen Hacker und Abstürze.

Fazit:
Die Arbeit zeigt uns, dass Sicherheit oft bedeutet, alte Gewohnheiten aufzugeben. Wir müssen aufhören, mit „Zetteln" zu arbeiten, die wir nach Belieben ändern können, und stattdessen lernen, mit „Sicherheitsausweisen" umzugehen, die uns genau sagen, was wir dürfen und was nicht. Es ist wie der Übergang von einem offenen Lagerhaus, in dem jeder alles anfassen darf, zu einem hochgesicherten Banktresor, in dem jeder Schritt überwacht wird – und das ist genau das, was wir für sichere Software brauchen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby" auf Deutsch:

Problemstellung

CHERI (Capability Hardware Enhanced RISC Instructions) ist eine neuartige Hardware-Architektur, die Speicher-Sicherheitsprobleme durch den Ersatz traditioneller Zeiger durch hardwareerzwungene „Capabilities" (Fähigkeiten) adressiert. Obwohl Virtual Machines (VMs) von dieser Sicherheit profitieren können, ist die Portierung bestehender VMs auf CHERI eine komplexe Aufgabe.

Das Hauptproblem liegt in den impliziten Annahmen über das undefinierte Verhalten (Undefined Behavior, UB) der C-Sprache, die auf herkömmlichen Architekturen funktionieren, aber auf CHERI zu Fehlern führen. VMs nutzen oft Techniken, die auf der Annahme basieren, dass Zeiger und Ganzzahlen austauschbar sind oder dass Speicherbereiche dynamisch erweitert werden können, ohne dass die Metadaten (wie Bounds oder Berechtigungen) der Capabilities beeinträchtigt werden. Diese Annahmen kollidieren mit dem strengen Sicherheitsmodell von CHERI, was zu unerwarteten Abstürzen (z. B. Bounds-Faults oder Tag-Faults) führt. Bisherige Arbeiten konzentrierten sich eher auf den allgemeinen Portierungsprozess oder spezifische Compiler-Probleme, nicht jedoch auf die spezifischen Fallstricke bei der Implementierung von VMs.

Methodik

Die Autoren führten eine Fallstudie durch, bei der sie CRuby (die Referenz-Implementierung der Ruby-Sprache, Version 3.4.1) auf die CHERI-Architektur (emuliertes CHERI-RISC-V im Pure-Capability-Modus) portierten.

• Umfang: Die Portierung umfasste das Laufzeitsystem und den Interpreter, schloss jedoch den JIT-Compiler und die Foreign Function Interface (FFI) aus.
• Analyse: Neben der eigenen Portierung wurden drei vorherige Fallstudien (MicroPython, JavaScriptCore, Rust) untersucht, um ein umfassendes Bild der Probleme zu erhalten.
• Kategorisierung: Die identifizierten Probleme wurden in sechs Kategorien basierend auf ihren Ursachen gruppiert.
• Validierung: Die Wirksamkeit der vorgeschlagenen Lösungen (Workarounds) wurde durch die erfolgreiche Anwendung auf CRuby und die Überprüfung der Codebasen der anderen Fallstudien verifiziert.
• Performance-Benchmarking: Die Leistung der portierten VM wurde mit der Original-VM auf x86-Hardware verglichen, um die Overheads der Lösungen zu messen.

Schlüsselergebnisse und Kategorien von Fallstricken

Die Autoren identifizierten und kategorisierten folgende Hauptprobleme:

1. Ungültige abgeleitete Zeiger (Invalid Derived Pointer):

   • Problem: VMs leiten oft Zeiger von anderen ab (z. B. Adressen lokaler Variablen für Stack-Scanning). Auf herkömmlichen Systemen ist dies sicher, aber in CHERI erbt der abgeleitete Zeiger die engen Bounds des Ursprungszeigers. Ein Iterieren über den Stack führt zu Bounds-Verletzungen.
   • Lösung: Beibehaltung eines „Super-Capability" mit weiten Bounds (z. B. für den gesamten Stack), von dem neue Zeiger abgeleitet werden.

2. Dereferenzierung ambiger Zeiger (Dereferencing Ambiguous Pointers):

   • Problem: Konservative Garbage Collector (GC) scannen den Stack nach Werten, die wie Zeiger aussehen (Bitmuster-Prüfung). Auf CHERI sind Ganzzahlen, die wie Zeiger aussehen, keine gültigen Capabilities (fehlendes Validitäts-Tag), was zu Tag-Faults führt.
   • Lösung: Vor dem Dereferenzieren muss das Validitäts-Tag des Capabilities geprüft werden, anstatt nur das Bitmuster zu analysieren. Dies ermöglicht zudem präzisere GC-Verfahren ohne Pinning.

3. In-Place-Reallokierung (In-Place Reallocation):

   • Problem: VMs nutzen oft benutzerdefinierte Allocatoren, die bei erfolgreicher In-Place-Reallokierung den alten Zeiger weiterverwenden. In CHERI kann realloc jedoch ein neues Capability mit anderen Bounds zurückgeben. Das Weiterverwenden des alten Zeigers führt zu Bounds-Faults beim Zugriff auf den erweiterten Bereich.
   • Lösung: Vermeidung der Abhängigkeit von In-Place-Reallokierung. Alle Zeiger müssen aktualisiert werden, wenn sich die Bounds ändern.

4. Nutzung von Padding-Bits ganzzahliger Typen (Using Padding Bits):

   • Problem: VMs packen oft kleine Werte in Ganzzahlen (z. B. Bitmaps für GC, Shape-IDs). In CHERI ist (u)intptr_t ein Capability (128 Bit), wobei die oberen 64 Bit Metadaten (Bounds) enthalten und die unteren 64 Bit für Daten genutzt werden können. Bit-Operationen (Shifts) auf diesen Typen führen zu undefiniertem Verhalten oder falschen Ergebnissen, wenn die Verschiebung die nutzbare Breite (64 Bit) überschreitet.
   • Lösung: Verwendung von exakten Ganzzahltypen (z. B. uint64_t) für Bitmanipulationen, die keine Pointer-Informationen enthalten.

5. Modifikation temporärer Capabilities durch den Compiler:

   • Problem: Der CHERI-Compiler generiert Code, der Metadaten von Operanden auf das Ergebnis überträgt. Bei Operationen auf sealed Capabilities (z. B. Rückkehradressen oder verschlüsselte Funktionszeiger) führt dies zu einem „Sealed Fault", da die Metadaten nicht verändert werden dürfen.
   • Lösung: Umwandlung von uintptr_t in nicht-Capability-Typen (z. B. uint64_t) vor der Operation, um die Erzeugung temporärer Capabilities zu verhindern.

6. Zeigerarithmetik auf Nicht-Capability-Typen:

   • Problem: Das Umwandeln von Zeigern in size_t (oder andere nicht-Capability-Typen) für Berechnungen und das Zurückcasten führt zu ungültigen Capabilities, da die Metadaten verloren gehen.
   • Lösung: Strikte Verwendung von (u)intptr_t für alle Zeigerarithmetik-Operationen.

Ergebnisse und Performance

• Portierungserfolg: Die portierte CRuby-Version bestand 29.609 von 34.046 Testfällen (ca. 87 %). Die meisten verbleibenden Fehler waren auf fehlende Bibliotheken (libyaml) oder einen einzelnen Absturz in einem AST-Test zurückzuführen, nicht auf fundamentale CHERI-Probleme.
• Code-Änderungen: Nur 464 Zeilen in 40 Dateien mussten geändert werden (ca. 0,077 % des gesamten Codebases), was die Machbarkeit der Portierung unterstreicht.
• Performance: Der Durchsatz der portierten VM lag im Durchschnitt bei 0,982-fach der Original-VM auf x86-Hardware (mit einer Standardabweichung von 0,038).
  • Ausreißer: Fiber-Operationen zeigten eine deutlich schlechtere Performance (bis zu 10-fach langsamer), da die portierte Version eine allgemeine Implementierung nutzte, während die Original-VM auf x86 optimierte Assembly-Code verwendete.
  • Fazit: Die Workarounds führen im Allgemeinen zu vernachlässigbarem Performance-Overhead.

Bedeutung und Beitrag

Dieses Paper leistet einen wesentlichen Beitrag zur Wissensbasis über die Entwicklung und Portierung von VMs auf CHERI:

1. Systematisierung: Es bietet die erste detaillierte Kategorisierung von VM-spezifischen Fallstricken auf CHERI, die über allgemeine Programmierhinweise hinausgeht.
2. Praktische Leitlinien: Die Autoren liefern konkrete, bewährte Workarounds für häufige VM-Idiome (insbesondere im Bereich GC und Speicherverwaltung), die Entwicklern helfen, sichere VMs zu konstruieren.
3. Sicherheitsgewinn: Durch die Nutzung von CHERI-Features (wie Validitäts-Tags) können VMs nicht nur sicherer werden, sondern auch effizientere und präzisere Garbage-Collector-Strategien implementieren.
4. Richtungweisend: Die Arbeit zeigt, dass die Portierung komplexer VMs wie CRuby auf CHERI machbar ist, ohne massive Performance-Einbußen, und legt den Grundstein für zukünftige, sicherere Laufzeitumgebungen.