Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

Dit artikel analyseert de valkuilen bij het porten van virtuele machines zoals CRuby naar CHERI, waarbij het specifiek ingaat op de conflicten tussen C-idioms en het strengere CHERI-beveiligingsmodel, en biedt werkoplossingen om veiligere VM-implementaties te realiseren.

De kern

Hier is een uitleg van het paper "Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby", vertaald naar begrijpelijk Nederlands met behulp van alledaagse analogieën.

De Kern: Een Veiligheidswet die te streng is voor oude gewoonten

Stel je voor dat CHERI een nieuw, superveilig type sleutelbord is voor computers. In de oude wereld (de traditionele architectuur) zijn sleutels (pointers) gewoon nummers die aangeven waar iets in het huis (het geheugen) staat. Je kunt met die nummers doen wat je wilt: ze optellen, aftrekken, en ze gebruiken om naar elke deur te lopen, zelfs als je daar geen toestemming voor hebt.

CHERI vervangt deze simpele nummers door slimme sleutels (capabilities). Deze sleutels zijn niet alleen een adres, maar dragen ook een paspoort mee met regels:

1. Grens: Je mag alleen naar deuren in een specifieke kamer lopen (geen toegang tot de zolder of de kelder).
2. Rechten: Je mag alleen binnenkomen, maar niet meubels verplaatsen (lezen, maar niet schrijven).
3. Geldigheid: De sleutel heeft een hologram (een 'tag'). Als het hologram verdwenen is, werkt de sleutel niet meer.

Het probleem? De programmeurs van CRuby (de motor achter de programmeertaal Ruby) zijn gewend aan de oude, losse wereld. Ze hebben code geschreven die doet alsof alle sleutels simpele nummers zijn. Toen ze deze code probeerden te laten werken op het nieuwe, strenge CHERI-systeem, botste het. De code probeerde dingen te doen die op de oude manier "gewoon werkten", maar op de nieuwe manier direct werden gestopt omdat ze de regels van de slimme sleutels schonden.

De 6 Valkuilen (De "Pitfalls")

De auteurs hebben de CRuby-code onderzocht en zes soorten fouten gevonden. Hier zijn ze, vertaald naar alledaagse situaties:

1. De "Verkeerde Kaart" (Invalid Derived Pointer)

• Het probleem: Stel je voor dat je een sleutel hebt die alleen toegang geeft tot je eigen slaapkamer. Je probeert nu een nieuwe sleutel te maken die toegang geeft tot het hele huis door gewoon een stukje van je oude sleutel te kopiëren en er een getal bij te tellen. Op de oude manier werkt dit; op CHERI niet, want de nieuwe sleutel heeft nog steeds de beperkingen van de oude.
• In de praktijk: De Ruby-VM probeerde een adres op te halen van een lokale variabele (een klein stukje geheugen) en dacht dat dit het begin van de hele stapel was. Omdat de originele sleutel maar een klein stukje dekte, viel de nieuwe "sleutel" buiten de grenzen.
• De oplossing: Gebruik een "meestersleutel" (super capability) die het hele huis dekt, en maak daar nieuwe sleutels van.

2. De "Valse Vriend" (Dereferencing Ambiguous Pointers)

• Het probleem: De Ruby-VM kijkt naar een hoop getallen en zegt: "Dit getal lijkt op een adres, dus ik ga erheen en kijk wat er staat." Op de oude manier was dat veilig genoeg. Op CHERI is een getal dat op een adres lijkt, geen echte sleutel. Het mist het hologram (de geldigheid). Als je probeert erin te kijken, gaat het alarm af.
• In de praktijk: De "Garbage Collector" (de schoonmaker die dode objecten opruimt) dacht dat een willekeurig getal een verwijzing naar een object was. Omdat het getal geen geldige sleutel was, crashte het systeem.
• De oplossing: Kijk eerst naar het hologram. Is het hologram aanwezig? Ja? Dan is het een echte sleutel. Nee? Laat het dan links liggen, ook al lijkt het op een adres.

3. De "Verhuizing die niet werkt" (In-Place Reallocation)

• Het probleem: Stel je voor dat je een koffer hebt (geheugen) en je wilt hem groter maken zonder hem te verplaatsen. Op de oude manier zei je: "Oké, ik gebruik nog steeds dezelfde sleutel voor de koffer, alleen is hij nu groter." Op CHERI is de sleutel echter gekoppeld aan de oude grootte. Als je de koffer vergroot, past de oude sleutel niet meer bij de nieuwe randen.
• In de praktijk: De VM probeerde een blok geheugen uit te breiden en dacht dat de oude sleutel nog steeds werkte voor het nieuwe, grotere deel. CHERI blokkeerde dit omdat de grenzen van de sleutel niet overeenkwamen met de nieuwe grootte.
• De oplossing: Gebruik altijd de nieuwe sleutel die je krijgt na het uitbreiden, en gooi de oude weg.

4. De "Lege Ruimte" (Using Padding Bits)

• Het probleem: In de oude wereld zijn alle bits in een getal nuttig. In de CHERI-wereld zijn de bovenste bits van een "sleutel-getal" (uintptr_t) echter gereserveerd voor paspoortgegevens (metadata). Ze zijn als "lege ruimte" in een koffer die je niet mag gebruiken voor je kleding.
• In de praktijk: Ruby probeerde kleine stukjes informatie (zoals vlaggetjes) in de bovenste bits van een getal te verstoppen. Omdat deze bits op CHERI gereserveerd zijn voor metadata, werden de data overschreven of genegeerd.
• De oplossing: Gebruik voor het opslaan van data puur "lege" getallen (zoals uint64_t) die geen paspoortinhoud hebben, zodat je alle bits kunt gebruiken.

5. De "Gegoten Sleutel" (Modifying Temporary Capabilities)

• Het probleem: Sommige sleutels zijn "afgegoten" (sealed). Ze zijn zo gemaakt dat je ze nooit meer kunt aanpassen. Als je probeert ze te veranderen, breekt de sleutel.
• In de praktijk: De computer zelf maakt soms tijdelijke versies van deze afgegoten sleutels om berekeningen te doen. De programmeur dacht: "Ik tel gewoon twee getallen op." Maar omdat de computer een afgegoten sleutel gebruikte, probeerde hij die te veranderen, wat verboden is.
• De oplossing: Zet de afgegoten sleutel eerst om in een gewoon getal (zonder paspoort), doe de berekening, en gebruik het resultaat als een getal.

6. De "Verkeerde Rekenmachine" (Pointer Arithmetic on Non-Capability Type)

• Het probleem: Soms gebruiken programmeurs de verkeerde "rekenmachine" om met adressen te rekenen. Ze gebruiken een rekenmachine voor gewone maten (size_t) in plaats van de speciale rekenmachine voor sleutels (uintptr_t).
• In de praktijk: Ruby rekende afstanden uit met een type dat niet geschikt was voor slimme sleutels. Het resultaat was een "sleutel" die eruitzag als een sleutel, maar geen geldig hologram had.
• De oplossing: Gebruik altijd de juiste, speciale rekenmachine (uintptr_t) die weet hoe het om moet gaan met de regels van de slimme sleutels.

Wat betekent dit voor de toekomst?

De auteurs hebben CRuby succesvol aangepast. Ze hebben de code "opgepoetst" zodat het werkt op het nieuwe, veilige systeem.

• Snelheid: Het nieuwe systeem is bijna even snel als het oude (ongeveer 98% van de snelheid).
• Veiligheid: Het grootste voordeel is dat het systeem nu veel veiliger is. Veel hacks die mogelijk waren op de oude manier, zijn nu onmogelijk omdat de "slimme sleutels" de regels streng bewaken.

Conclusie:
Het porten van complexe software (zoals een VM) naar een veiliger systeem is als het verhuizen van een oud huis naar een nieuw, streng beveiligd complex. Je kunt niet zomaar je oude sleutels gebruiken; je moet je gewoonten aanpassen en nieuwe regels leren. Dit paper is een handleiding voor die verhuizing, zodat anderen niet dezelfde fouten maken.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby" in het Nederlands.

Probleemstelling

CHERI (Capability Hardware Enhanced RISC Instructions) is een nieuwe hardware-architectuur die memory safety verbetert door traditionele pointers te vervangen door onvervalste "capabilities" (bevoegdheden) met metadata zoals grenzen (bounds) en permissies. Hoewel Virtual Machines (VM's) zoals CRuby (de referentie-implementatie van Ruby) profiteren van deze beveiliging, is het porten van dergelijke complexe systemen naar CHERI geen triviaal proces.

Het kernprobleem is dat VM-implementaties vaak afhankelijk zijn van gedefinieerd gedrag (undefined behavior) en aannames over traditionele architecturen die in strijd zijn met het strikte CHERI-model. Veel VM's gebruiken C-idiomen die op conventionele systemen werken (bijvoorbeeld het manipuleren van pointers als gehele getallen of het aannemen dat alle bits van een integer beschikbaar zijn), maar die in CHERI leiden tot hardware-fouten (zoals capability bounds faults of tag faults). Bestaande gidsen voor CHERI-programmering zijn te algemeen en behandelen niet de specifieke valkuilen die ontstaan bij het implementeren van VM-runtime systemen.

Methodologie

De auteurs hebben een case study uitgevoerd door CRuby (versie 3.4.1) te porten naar de CHERI-architectuur (specifiek de purecap-modus op CHERI-RISC-V).

• Scope: Ze focusten op het runtime-systeem en de interpreter, exclusief de JIT-compiler en de Foreign Function Interface (FFI).
• Proces: Ze compileerden de broncode met de CHERI C-toolchain, corrigeerden compiler-fouten, en draaiden de test suites (basictest, bootstraptest, test).
• Analyse: Ze identificeerden fouten, categoriseerden deze op basis van de onderliggende oorzaak, en vergeleken hun bevindingen met eerdere case studies (MicroPython, JavaScriptCore, en Rust).
• Validatie: Ze verifieerden de werkbaarheid van hun oplossingen (workarounds) door deze toe te passen op CRuby en door de codebases van andere projecten te analyseren.

Belangrijkste Bijdragen en Valkuilen

De auteurs hebben zes categorieën van specifieke valkuilen geïdentificeerd die VM's tegenkomen bij het porten naar CHERI, voornamelijk veroorzaakt door misvattingen over het C-standaardgedrag:

1. Ongeldige Afgeleide Pointers (Invalid Derived Pointers):

   • Probleem: VM's leiden vaak een pointer af van een andere pointer voor een ander doel (bijv. het nemen van het adres van een lokale variabele om de stack-top te vinden). In CHERI heeft een capability echter strikte grenzen die alleen het oorspronkelijke object dekken. Het afleiden van een pointer die verder reikt dan deze grenzen veroorzaakt een bounds-fout.
   • Oplossing: Behoud een "super-capability" met voldoende brede grenzen (bijv. de volledige stack) waaruit nieuwe pointers veilig kunnen worden afgeleid.

2. Dereferencing van Ambigue Pointers:

   • Probleem: Conservatieve Garbage Collectors (GC) scannen de stack op waarden die op pointers lijken (bitpatroon) en proberen ze te dereferenceren. In CHERI zijn integers geen geldige capabilities; het dereferenceren van een geconverteerde integer (zonder geldig tag) veroorzaakt een tag-fout.
   • Oplossing: Gebruik de validiteitstags van CHERI om te controleren of een waarde daadwerkelijk een geldige capability is voordat deze wordt gedereferenceerd, in plaats van te vertrouwen op bitpatronen.

3. In-Place Reallocation:

   • Probleem: VM's vertrouwen vaak op realloc die in-place werkt en dezelfde pointer teruggeeft, zelfs als de buffer groeit. In CHERI kan een nieuwe capability echter andere (breder) grenzen hebben dan de oude. Het gebruik van de oude pointer voor de nieuwe, grotere regio leidt tot bounds-fouten.
   • Oplossing: Vermijd afhankelijkheid van in-place reallocation. Als het toch gebeurt, moeten alle verwijzingen naar de oude pointer worden bijgewerkt naar de nieuwe capability.

4. Gebruik van Padding-bits van Integer Types:

   • Probleem: VM's packen vaak kleine waarden in integers (bitmaps, shape IDs) of gebruiken bit-shifts. In CHERI is (u)intptr_t een capability waarbij de bovenste 64 bits metadata bevatten (padding voor de integer-waarde). Bit-operaties op deze types kunnen leiden tot ongedefinieerd gedrag of het negeren van de metadata.
   • Oplossing: Gebruik exacte integer-types (zoals uint64_t) voor bit-manipulatie en vermijd het gebruik van (u)intptr_t voor data die geen pointer is.

5. Modificatie van Tijdelijke Capabilities door de Compiler:

   • Probleem: CHERI vereist dat gesealde capabilities (zoals return-adressen) niet gewijzigd worden. De compiler genereert echter code die metadata overneemt bij binaire operaties, wat een tijdelijke capability creëert. Als de operand geseald is, veroorzaakt dit een "sealed fault".
   • Oplossing: Cast (u)intptr_t operanden naar niet-capability types (zoals uint64_t) voordat er binaire operaties worden uitgevoerd, zodat de compiler geen tijdelijke capability hoeft te maken.

6. Pointer Arithmetic op Niet-Capability Types:

   • Probleem: Het uitvoeren van pointer-arithmetic door een pointer te casten naar een type zoals size_t en terug, werkt niet in CHERI omdat size_t geen capability is. Dit resulteert in ongeldige capabilities na het terugcasten.
   • Oplossing: Gebruik uitsluitend (u)intptr_t voor pointer-arithmetic.

Resultaten

• Functionaliteit: De gepordeerde CRuby slaagt voor 29.609 van de 34.046 testcases. De meeste mislukkingen (ongeveer 2.931) komen voort uit één testprogramma dat crashde door een onopgeloste valkuil, en een gebrek aan de libyaml bibliotheek.
• Performance: De performance-overhead van de werkoplossingen is minimaal. Gemiddeld draait de gepordeerde Ruby VM op 0,982x de throughput van de originele VM (met een standaardafwijking van 0,038).
  • Enkele uitschieters (tot 10x trager) werden waargenomen bij benchmarks gerelateerd aan "fibers" (cooperatieve multitasking), omdat de originele VM geoptimaliseerde assembly-code voor x86 gebruikt, terwijl de CHERI-versie een generieke implementatie moet gebruiken.
• Validatie: De werkoplossingen bleken effectief en toepasbaar op andere projecten zoals MicroPython en JavaScriptCore.

Significantie

Dit artikel levert een cruciale bijdrage aan de kennisbasis voor het ontwikkelen van veilige software op CHERI-architecturen.

1. Praktische Gids: Het biedt een gedetailleerde lijst van specifieke valkuilen voor VM-ontwikkelaars, verder dan de algemene CHERI-programmeergids.
2. Beveiliging vs. Performance: Het toont aan dat het oplossen van deze problemen (zoals het gebruik van validiteitstags in de GC) niet alleen noodzakelijk is voor correctheid, maar ook kansen biedt voor veiligere en mogelijk snellere implementaties (bijv. het elimineren van "pinning" in GC).
3. Toekomstige Ontwikkeling: Het onderstreept dat VM's, die vaak complexe C-idiomen gebruiken, zorgvuldig moeten worden herschreven om volledig te profiteren van de memory safety van CHERI, zonder de prestaties significant te verlagen.

Kortom, het werk demonstreert dat het mogelijk is om complexe VM's succesvol te porten naar CHERI, mits ontwikkelaars zich bewust zijn van en rekening houden met de fundamentele verschillen in hoe CHERI pointers en geheugen behandelt ten opzichte van traditionele systemen.