GPU-Fuzz: Finding Memory Errors in Deep Learning Frameworks

Die Arbeit stellt GPU-Fuzz vor, einen Fuzzer, der durch die Modellierung von Operator-Parametern als formale Constraints und deren Lösung effizient Speicherfehler in Deep-Learning-Frameworks wie PyTorch, TensorFlow und PaddlePaddle aufdeckt, wobei 13 bisher unbekannte Bugs identifiziert wurden.

Das Wesentliche

Das Problem: Der stille Killer im Computer

Stellen Sie sich vor, ein Deep-Learning-Framework (wie PyTorch oder TensorFlow) ist wie ein riesiges, hochmodernes Kochrestaurant. Die Chefs (die KI-Modelle) geben Befehle: „Mach eine Suppe!" oder „Brate das Steak!".

Aber im Hintergrund arbeiten hunderte von Köchen (den GPU-Kernen), die die eigentliche Arbeit verrichten. Diese Köche arbeiten extrem schnell und parallel. Das Problem ist: Manchmal machen sie Fehler beim Umgang mit den Zutaten (dem Speicher).

• Der Fehler: Ein Koch greift vielleicht in einen Topf, der gar nicht ihm gehört, oder er kippt Zutaten in einen Eimer, der schon voll ist.
• Die Gefahr: Oft passiert das so leise, dass niemand es merkt. Das Essen (die KI-Ergebnisse) schmeckt vielleicht komisch, oder der Topf platzt. In schlimmen Fällen kann das ganze Restaurant (der Computer) abstürzen oder Hacker können sich in die Küche schleichen.

Bisherige Werkzeuge zum Testen dieser Systeme (Fuzzer) haben sich nur darauf konzentriert, neue Rezepte zu erfinden. Sie haben gefragt: „Was passiert, wenn wir eine ganz neue Art von Suppe kochen?" Aber sie haben nicht genau genug hingeschaut, wie die Köche mit den Zutaten umgehen, wenn die Mengen oder Formen am Rand des Möglichen liegen.

Die Lösung: GPU-Fuzz – Der Detektiv für die Details

Die Forscher haben ein neues Werkzeug namens GPU-Fuzz entwickelt. Statt neue Rezepte zu erfinden, schauen sie sich genau an, wie die Köche mit den Zutaten-Parametern umgehen.

Stellen Sie sich GPU-Fuzz wie einen sehr pedantischen Qualitätsprüfer vor, der eine spezielle Brille trägt:

1. Die Brille (Formale Constraints):
   Der Qualitätsprüfer kennt die strengen Regeln der Küche. Er weiß genau: „Wenn der Topf 5 Liter fasst und du 3 Liter Wasser und 2 Liter Suppe hineingießst, darf der Deckel nicht zu groß sein."
   Er übersetzt diese Regeln in eine mathematische Sprache, die ein Computer versteht (ein sogenannter „Constraint Solver").

2. Die Suche nach den Ecken (Parameter-Space Exploration):
   Normale Tester probieren zufällige Mengen aus (z. B. 100g Salz). GPU-Fuzz sucht aber gezielt nach den Grenzfällen.

   • Metapher: Es ist, als würde ein Sicherheitsbeamter nicht nur die Haupttür prüfen, sondern gezielt nachsehen, was passiert, wenn jemand versucht, durch ein Fenster zu klettern, das nur 1 Millimeter größer ist als erlaubt.
   • Der Prüfer sagt dem Computer: „Gib mir eine Konfiguration, bei der die Menge genau so groß ist, dass sie fast den Topf sprengt, aber noch nicht ganz."

3. Der Test (Cross-Framework Execution):
   Sobald GPU-Fuzz eine solche „gefährliche" Kombination gefunden hat, probiert er sie in verschiedenen Küchen aus (PyTorch, TensorFlow, PaddlePaddle). Er nutzt ein Werkzeug namens compute-sanitizer, das wie ein Röntgenbild funktioniert: Es sieht sofort, wenn ein Koch versehentlich in den falschen Topf greift, selbst wenn das Essen danach noch gut aussieht.

Was haben sie gefunden?

Das Team hat mit GPU-Fuzz 13 bisher unbekannte Fehler in den großen KI-Frameworks gefunden.

• Das Besondere: Viele dieser Fehler waren „stille Killer". Das Programm lief nicht ab, aber im Hintergrund wurden Daten beschädigt.
• Ein konkretes Beispiel: Ein Koch (der Code) rechnete die Anzahl der Zutaten aus. Durch einen Rechenfehler (Überlauf) dachte er, er hätte Platz für 100 Eier, obwohl er eigentlich Platz für 100 Millionen hatte. Er griff dann in den falschen Bereich des Kühlschranks. GPU-Fuzz hat genau diese Kombination aus riesigen Zahlen und kleinen Topfgrößen gefunden, die niemand sonst getestet hätte.

Warum ist das wichtig?

Bisher haben Tester versucht, die Komplexität der Rezepte (die Struktur des neuronalen Netzwerks) zu testen. GPU-Fuzz zeigt, dass wir auch die Feinheiten der Zubereitung (die Parameter der einzelnen Funktionen) testen müssen.

Zusammenfassend:
GPU-Fuzz ist wie ein Spezialdetektiv, der nicht nach neuen Verbrechen sucht, sondern die alten, gut versteckten Ecken und Kanten der Küche inspiziert, bevor ein echter Hacker oder ein fataler Fehler zuschlägt. Es füllt eine Lücke, die bisherige Sicherheitschecks übersehen haben, und macht unsere KI-Systeme sicherer.

Technische Zusammenfassung

1. Problemstellung

Deep-Learning-Frameworks (DL) wie PyTorch, TensorFlow und PaddlePaddle sind stark von GPU-Beschleunigung abhängig. Die Korrektheit dieser Berechnungen wird jedoch häufig durch Speicherfehler in den zugrunde liegenden CUDA-Kernen bedroht. Diese Fehler, wie z. B. Zugriffe außerhalb der Grenzen (Out-of-Bounds, OOB) oder falsch ausgerichtete Speicheradressen, führen nicht nur zu Systemabstürzen, sondern oft zu stiller Datenkorruption (silent data corruption), die schwer zu erkennen ist und Sicherheitslücken (z. B. ROP-Angriffe) eröffnet.

Bestehende Fuzzing-Tools für DL-Systeme (wie NNSmith) konzentrieren sich primär auf die Generierung diverser neuronaler Netzwerkstrukturen, um arithmetische Fehler in Compilern zu finden. Dieser Ansatz ignoriert jedoch den Parameterraum einzelner Operatoren. Da Speicherfehler oft durch spezifische, grenzwertige Kombinationen von Tensor-Formen, Datentypen, Strides und Padding ausgelöst werden, bleiben diese durch strukturelles Fuzzing unentdeckt.

2. Methodik: GPU-Fuzz

GPU-Fuzz ist ein neuer Fuzzer, der den Fokus von der Netzwerkstruktur auf die Operatorebene und die Speicherlayout-Parameter verlagert. Der Ansatz basiert auf drei Hauptschritten:

• Modellierung von Operatoren (Operator Modeling):
  GPU-Fuzz abstrahiert DL-Operatoren (z. B. Convolution, Pooling) durch ein formales Constraint-Modell. Die semantischen Regeln und mathematischen Beziehungen zwischen Parametern (z. B. Eingabegröße, Kernel-Größe, Padding, Stride) werden in symbolische Variablen und Constraints übersetzt.

  • Beispiel: Für eine Faltung gilt die Formel $H_{out} = \lfloor \frac{H_{in} + 2P - D(K-1) - 1}{S} \rfloor + 1$. Nur Konfigurationen, die diese und weitere Randbedingungen erfüllen, sind semantisch gültig.
  • Die Autoren extrahierten manuell Constraints für 13 verschiedene Operatoren aus der Dokumentation.

• Constraint-basierte Testfall-Generierung:
  Anstatt zufällige Eingaben zu generieren, nutzt GPU-Fuzz einen SMT-Solver (Z3), um konkrete Werte für die symbolischen Variablen zu finden, die die Constraints erfüllen.

  • Erweiterte Suchstrategie: Da SMT-Solver oft nur eine einzelne Lösung (häufig an Grenzen) zurückgeben, implementiert GPU-Fuzz eine iterative, constraint-gesteuerte Suchstrategie. Nach jeder gefundenen Lösung wird eine neue Constraint hinzugefügt, die den aktuellen Wert eines Parameters ausschließt (z. B. stride != 10).
  • Hash-basierte Constraints: Um die Vielfalt der Lösungen zu erhöhen und ähnliche Regionen im Parameterraum zu vermeiden, werden zusätzlich Hash-Funktionen verwendet (z. B. hash(stride) != hash(10)), um den Solver zu zwingen, in neue, ununtersuchte Bereiche zu navigieren.

• Cross-Framework-Execution:
  Die generierten abstrakten Parameter werden in konkrete API-Aufrufe für PyTorch, TensorFlow und PaddlePaddle übersetzt. Jede Ausführung wird mit NVIDIA Compute Sanitizer überwacht, um Speicherfehler (wie OOB-Zugriffe oder falsche Ausrichtung) in Echtzeit zu erkennen.

3. Wichtige Beiträge

• Neuer Fuzzing-Ansatz: Einführung einer Methode, die systematisch den Parameterraum von GPU-Operatoren erkundet, eine Dimension, die von bestehenden DL-Fuzzern vernachlässigt wird.
• Systemimplementierung: Entwicklung von GPU-Fuzz, das Constraint-Solving nutzt, um automatisch Testfälle für grenzwertige Bedingungen in CUDA-Kernen zu generieren.
• Entdeckung unbekannter Fehler: Demonstration der Effektivität durch die Aufdeckung von 13 bisher unbekannten Bugs in drei großen Frameworks.

4. Ergebnisse

In einer Evaluation auf einem Server mit NVIDIA H100 GPU wurden folgende Ergebnisse erzielt:

• Entdeckte Fehler: Insgesamt 13 neue Bugs wurden in PyTorch, TensorFlow und PaddlePaddle identifiziert.
  • Fehlerarten: 7 davon waren Speicherzugriffsverletzungen (z. B. OOB-Schreibzugriffe, falsche Ausrichtung).
  • Schweregrad: 5 dieser Fehler waren stille Speicherfehler (Silent Memory Corruption), die keine API-Ausnahmen auslösen und nur durch spezielle Tools wie Compute Sanitizer detektierbar sind. Weitere Fehler führten zu GPU-Level-Exceptions oder CPU-Seitigen Asserts.
  • Ursachen: Häufige Ursachen waren falsche Berechnungen von Grid-Abmessungen, Integer-Overflows bei der Umwandlung von 64-Bit auf 32-Bit Integer-Werten und fehlerhafte Randbedingungen in CUDA-Kernen.
• Vergleich mit NNSmith:
  • GPU-Fuzz generierte im Durchschnitt fast dreimal so viele Testfälle (ca. 51.860 vs. 19.063) wie NNSmith.
  • Während NNSmith hauptsächlich numerische Inkonsistenzen fand, entdeckte GPU-Fuzz 26 ± 5 kritische Speicherfehler pro Lauf. NNSmith fand in diesem Szenario keine Speicherfehler.
  • Dies zeigt, dass GPU-Fuzz eine Lücke im Sicherheits-Testing schließt, die durch rein strukturelles Fuzzing nicht abgedeckt wird.

5. Bedeutung und Fazit

Das Paper unterstreicht, dass die Sicherheit moderner KI-Systeme nicht nur durch das Testen von Netzwerkarchitekturen, sondern zwingend durch das systematische Testen der Operatoren-Parameter gewährleistet werden muss.

• Sicherheitsrelevanz: Die aufgedeckten Fehler können zu Datenkorruption, Informationslecks oder Systemübernahmen führen, insbesondere da viele davon „stille" Fehler sind, die in Produktionsumgebungen unbemerkt bleiben.
• Paradigmenwechsel: GPU-Fuzz beweist, dass eine Kombination aus formaler Constraint-Modellierung und Fuzzing effektiver ist als reine Zufallsgenerierung für das Auffinden komplexer Speicherfehler.
• Ausblick: Die Autoren arbeiten an der Erweiterung der Constraint-Bibliothek auf weitere Operatoren und der Verbesserung der Orakel (z. B. durch differentielles Fuzzing gegen CPU-Implementierungen), um auch numerische Korrektheitsprobleme zu erfassen.

Zusammenfassend stellt GPU-Fuzz einen wesentlichen Fortschritt in der Sicherheitsforschung für Deep-Learning-Frameworks dar, indem es die oft übersehene Ebene der GPU-Kernel-Implementierung gezielt auf Schwachstellen untersucht.