GPU-Fuzz: Finding Memory Errors in Deep Learning Frameworks

Dit paper introduceert GPU-Fuzz, een fuzzing-tool die door het modelleren van operatorparameters als formele constraints en het gebruik van een constraint solver, efficiënt geheugenfouten in deep learning-frameworks zoals PyTorch, TensorFlow en PaddlePaddle opspoort.

De kern

🧠 De Onzichtbare Lekken in de Supercomputer

Stel je voor dat Deep Learning-frameworks (zoals PyTorch of TensorFlow) enorme, superkrachtige fabrieken zijn. In deze fabrieken worden AI-modellen gebouwd. De machines die het zware werk doen, zijn de GPU's (grafische kaarten). Deze GPU's zijn als legers van duizenden kleine werknemers die allemaal tegelijkertijd rekenen.

Het probleem? Soms maken deze werknemers een foutje. Ze proberen iets te pakken wat ze niet mogen aanraken, of ze schrijven op een plek waar ze niet horen te zijn. In de programmeertaal noemen we dit geheugenfouten.

Deze fouten zijn gevaarlijk omdat ze vaak stil zijn. De fabriek crasht niet direct, maar de producten (de AI-resultaten) zijn bedorven. Het is alsof een bakker per ongeluk gif in de cake doet, maar de cake er nog steeds perfect uitziet.

🔍 Wat is GPU-Fuzz?

De onderzoekers van dit paper hebben een nieuwe tool bedacht die GPU-Fuzz heet. Je kunt je dit voorstellen als een super-geavanceerde testpiloot die speciaal is getraind om die verborgen lekken te vinden.

Voordat GPU-Fuzz er was, keken andere testtools (zoals NNSmith) vooral naar de ontwerpplannen van de AI. Ze bouwden steeds nieuwe, gekke gebouwen om te zien of de architectuur instabiel was. Maar GPU-Fuzz kijkt niet naar het gebouw, maar naar de gereedschappen die de werknemers gebruiken.

🛠 Hoe werkt het? (De Analogie van de Receptenboeken)

Stel je voor dat elke taak in de GPU (zoals een "convolutie" of "pooling") een recept is.

• De ingrediënten: De grootte van de data, de snelheid (stride), en de padding (marge).
• De regels: Er zijn wiskundige regels die zeggen welke ingrediëntencombinaties veilig zijn. Bijvoorbeeld: "Je kunt niet een taart bakken met een diameter van 10 meter als je oven maar 1 meter breed is."

Hoe andere tools werken:
Ze gooien willekeurige ingrediënten in de oven en hopen dat er een fout ontstaat. Dit is als blinddoek de keuken in rennen en hopen dat je per ongeluk de koelkast openlaat.

Hoe GPU-Fuzz werkt:
GPU-Fuzz is slim. Het leest eerst de receptenboeken (de documentatie van de software) en schrijft alle regels op in een streng wiskundig taal (constraints).

1. De Regels: Het zegt: "Oké, voor dit recept moet de breedte groter zijn dan de hoogte, en de snelheid moet een even getal zijn."
2. De Zoektocht: Vervolgens gebruikt het een slimme rekenmachine (een "constraint solver") om alle mogelijke combinaties te vinden die aan de regels voldoen, maar die toch net aan de rand van de afgrond zitten.
3. De Grensgevallen: Het zoekt specifiek naar de situaties waar de regels net niet meer werken. Bijvoorbeeld: "Wat gebeurt er als de snelheid precies 1000 is, in plaats van 999?"

Door systematisch naar deze randgevallen te kijken, vindt GPU-Fuzz de plekken waar de werknemers (de GPU-kernen) hun handen op de verkeerde plekken zetten.

🕵️‍♂️ Wat vonden ze?

De onderzoekers hebben GPU-Fuzz laten werken op drie grote AI-fabrieken: PyTorch, TensorFlow en PaddlePaddle.

Het resultaat? Ze vonden 13 nieuwe, onbekende fouten.

• Sommige fouten zorgden ervoor dat de computer crashte.
• Maar het gevaarlijkste waren de stille fouten. De computer bleef werken, maar de data werd corrupt. Het was alsof de werknemers per ongeluk de muren van de fabriek beschadigden zonder dat iemand het merkte.

Een voorbeeld uit het paper:
Bij een specifieke taak in PyTorch (ConvTranspose2d) vond de tool een combinatie van getallen die leek veilig, maar die in werkelijkheid een rekenfout veroorzaakte. De computer dacht dat er ruimte was voor 100 blokken, maar door een foutje in de code (een "integer overflow") dacht hij dat er ruimte was voor 10. De werknemers schreven dan data op plekken waar ze niet mochten, wat leidde tot een "out-of-bounds" fout.

🏆 Waarom is dit belangrijk?

1. Veiligheid: Als AI-systemen in ziekenhuizen of zelfrijdende auto's worden gebruikt, mag er geen enkele fout zijn. Een stil geheugenlek kan leiden tot dodelijke fouten in de diagnose of het sturen van de auto.
2. Een nieuwe kijk: Tot nu toe keken testers vooral naar de grote lijnen (de AI-modellen). GPU-Fuzz laat zien dat we ook diep in de kleine details (de parameters van de operatoren) moeten kijken.
3. Complementair: Het is niet één of het ander. Je hebt zowel de test voor het gebouw (NNSmith) als de test voor de gereedschappen (GPU-Fuzz) nodig om een veilige fabriek te hebben.

🚀 Conclusie

Kortom: GPU-Fuzz is een slimme tool die de "recepten" van AI-software leest en systematisch op zoek gaat naar de gevaarlijkste combinaties van getallen. Door dit te doen, vinden ze de verborgen lekken in de geheugens van onze krachtigste computers, voordat hackers of ongelukken ze kunnen misbruiken.

Het is alsof je een inspecteur bent die niet alleen kijkt of het dak niet lekt, maar ook elke steen in de muur controleert op barstjes die je met het blote oog niet ziet.

Technische samenvatting

Probleemstelling

GPU-gebaseerde deep learning (DL) frameworks zoals PyTorch, TensorFlow en PaddlePaddle zijn essentieel voor moderne AI-toepassingen. De correctheid van deze systemen wordt echter vaak bedreigd door geheugenfouten (memory errors) in de onderliggende CUDA-kernels. Deze fouten, zoals toegang buiten de grenzen (out-of-bounds access) of verkeerd uitgelijnde geheugenadressering, kunnen leiden tot:

• Systeemcrashes.
• Stille data-corruptie (silent data corruption), waarbij het programma blijft draaien maar onjuiste resultaten produceert zonder waarschuwingen.
• Security-kwetsbaarheden, zoals het uitvoeren van kwaadaardige code via Return-Oriented Programming (ROP) of het manipuleren van instructies in het geheugen.

Bestaande fuzzers voor DL-systemen (zoals NNSmith) richten zich voornamelijk op het genereren van diverse neurale netwerkstructuren om rekenfouten in compilers te vinden. Deze aanpak is echter ongeschikt voor het vinden van geheugenfouten, omdat deze fouten niet worden veroorzaakt door de netwerkarchitectuur, maar door specifieke, vaak randvoorwaarden (boundary conditions) in de parameters van individuele operators (zoals tensor-vormen, strides, padding en data-types).

Methodologie: GPU-Fuzz

GPU-Fuzz is een nieuwe fuzzer die de focus verschuift van de netwerkstructuur naar de parameter-ruimte van operators. Het systeem werkt in drie hoofdfasen:

1. Operator Modeling (Operator Modelleren):

   • GPU-Fuzz abstracteert GPU-operators (bijv. convolutie, pooling) naar een formeel model.
   • De semantische regels en geheugenrelaties van een operator worden vertaald naar een set formele constraints (beperkingen) met symbolische variabelen.
   • Voorbeeld: Bij een convolutie-operator wordt de relatie tussen invoerhoogte ($H_{in}$), padding ($P$), kernelgrootte ($K$) en stride ($S$) uitgedrukt als een wiskundige formule ($H_{out} = \dots$).
   • Er zijn 45 constraints geëxtraheerd voor 13 verschillende operator-families.

2. Constraint-based Test Case Generation (Generatie op basis van Constraints):

   • Een SMT-oplosser (Z3) wordt gebruikt om concrete waarden te vinden die voldoen aan de constraints.
   • Innovatie: In plaats van slechts één oplossing te vinden, gebruikt GPU-Fuzz een iteratieve, constraint-gestuurde zoekstrategie.
   • Het systeem selecteert willekeurig een parameter, voegt een constraint toe om de huidige waarde uit te sluiten (bijv. $stride \neq 10$), en gebruikt ook hash-based constraints om de zoekruimte te diversifiëren. Dit dwingt de solver om systematisch nieuwe, ongeëxploreerde gebieden in de parameter-ruimte te verkennen, inclusief kritieke randvoorwaarden.

3. Cross-Framework Execution (Uitvoering over Frameworks):

   • De gegenereerde abstracte parameters worden vertaald naar concrete API-calls in meerdere frameworks (PyTorch, TensorFlow, PaddlePaddle).
   • Elke uitvoering wordt gemonitord met NVIDIA's compute-sanitizer, een tool die specifiek ontworpen is om geheugenfouten in CUDA-kernels te detecteren.
   • Als compute-sanitizer een fout detecteert, worden de logs gearchiveerd voor reproduceerbaarheid.

Belangrijkste Bijdragen

• Nieuwe Fuzzing-aanpak: Een methode die specifiek gericht is op het systematisch verkennen van de parameter-ruimte van operators, een dimensie die door bestaande DL-fuzzers wordt genegeerd.
• Systeemontwerp: De implementatie van GPU-Fuzz, dat constraint solving combineert met runtime-analyse om geheugenproblemen in low-level CUDA-kernels te vinden.
• Validatie: Het aantonen van de effectiviteit door 13 tot dan toe onbekende bugs te ontdekken in grote DL-frameworks.

Resultaten

In de evaluatie werden de volgende resultaten behaald:

• Bugs Ontdekt: In totaal werden 13 nieuwe bugs gevonden in PyTorch, TensorFlow en PaddlePaddle.
  • 7 geheugen-toegangsfouten (memory access violations), waaronder 5 gevallen van stille geheugen-corruptie die alleen detecteerbaar zijn met low-level tools zoals compute-sanitizer.
  • Andere fouten omvatten integer overflows, ongeldige launch-configuraties en API-uitzonderingen.
  • Een veelvoorkomende oorzaak bleek onjuiste berekening van grid-dimensies of gebrekkige grenscontroles in CUDA-kernels te zijn.
• Vergelijkende Studie:
  • In vergelijking met de state-of-the-art fuzzer NNSmith (die gericht is op compiler-fouten en numerieke inconsistenties), genereerde GPU-Fuzz bijna 3 keer meer testcases (51.860 vs 19.063).
  • Cruciaal: NNSmith vond geen enkele geheugenfout, terwijl GPU-Fuzz 26 ± 5 kritieke geheugenfouten en 80 configuratiefouten ontdekte.
  • Dit bevestigt dat GPU-Fuzz een "blinde vlek" in de beveiligingstesting van GPU's opvult die door andere tools wordt gemist.
• Case Study: Een proof-of-concept voor een bug in ConvTranspose2d van PyTorch toonde aan hoe een combinatie van extreme parameters (grote stride) leidde tot een integer overflow in de host-code, wat resulteerde in een te klein grid en daaropvolgende out-of-bounds schrijfacties in het geheugen.

Betekenis en Conclusie

GPU-Fuzz demonstreert dat het beveiligen van AI-systemen een bredere aanpak vereist dan alleen het testen van modelstructuren. Door zich te richten op de complexe parameter-ruimte van individuele operators, kan men kritieke, vaak stille geheugenfouten vinden die de betrouwbaarheid en veiligheid van AI-toepassingen (zoals in medische beeldvorming en autonoom rijden) in gevaar brengen.

De auteurs hebben verantwoordelijk gediscloseerd over alle gevonden bugs aan de ontwikkerteams van de betrokken frameworks. Het werk suggereert dat een combinatie van model-level fuzzing (zoals NNSmith) en operator-parameter fuzzing (zoals GPU-Fuzz) de meest robuuste strategie is voor het testen van deep learning frameworks.