GPU-Fuzz: Finding Memory Errors in Deep Learning Frameworks

Le papier présente GPU-Fuzz, un outil de fuzzing qui modélise les paramètres des opérateurs sous forme de contraintes formelles pour générer des cas de test ciblant les conditions limites des noyaux GPU, permettant ainsi de découvrir 13 bugs méconnus dans les frameworks d'apprentissage profond PyTorch, TensorFlow et PaddlePaddle.

L'essentiel

🧠 L'histoire en bref : Chasser les fantômes invisibles dans le cerveau de l'IA

Imaginez que les frameworks d'intelligence artificielle (comme PyTorch ou TensorFlow) sont de gigantesques usines à pizzas. Ces usines utilisent des robots ultra-rapides (les GPU) pour préparer des millions de pizzas à la seconde.

Le problème ? Parfois, un robot fait une erreur de calcul ou de mouvement. Il peut :

1. Lâcher une pizza sur le sol (crash du système).
2. Mettre un ingrédient dans la mauvaise boîte, mais personne ne s'en rend compte tout de suite (corruption silencieuse des données).
3. Ou pire, un pirate pourrait profiter de cette erreur pour voler la recette secrète de la pizza (faille de sécurité).

Ces erreurs sont souvent cachées dans les paramètres précis que les robots utilisent pour travailler (la taille de la pizza, la vitesse de la main, la distance entre les ingrédients).

🕵️‍♂️ Le détective : GPU-Fuzz

Les chercheurs ont créé un outil appelé GPU-Fuzz. Pour faire simple, c'est un inspecteur de sécurité très méticuleux qui ne regarde pas la recette globale de la pizza (la structure du réseau de neurones), mais qui se concentre uniquement sur les réglages des robots.

1. La vieille méthode (NNSmith) : "Jeter des pizzas au hasard"

Les anciens détectives (comme NNSmith) fonctionnaient un peu comme un enfant qui lance des boules de pâte au hasard pour voir si ça colle au mur. Ils créaient des réseaux de neurones très complexes et différents.

• Le problème : C'est efficace pour trouver des erreurs de goût (des calculs mathématiques faux), mais ils ne trouvent presque jamais les erreurs de sécurité (où le robot se cogne le doigt ou vole un ingrédient), car ces erreurs dépendent de réglages très précis et bizarres que le hasard ne rencontre pas souvent.

2. La nouvelle méthode (GPU-Fuzz) : "La règle mathématique"

GPU-Fuzz, lui, est plus intelligent. Il ne lance pas des choses au hasard. Il utilise une règle mathématique stricte (un "solveur de contraintes") pour comprendre exactement comment les robots doivent bouger.

• L'analogie du puzzle : Imaginez que vous avez un puzzle géant. Les anciens détectives essayaient de forcer les pièces ensemble n'importe comment. GPU-Fuzz, lui, lit le manuel d'instructions du puzzle. Il sait : "Si la pièce A fait 10 cm, la pièce B doit faire exactement 12 cm, sinon le robot va se cogner."
• Il utilise un cerveau mathématique (un logiciel appelé Z3) pour générer des milliers de combinaisons de réglages qui sont juste à la limite de ce qui est autorisé. C'est comme tester si un pont tient bon en y mettant exactement 1000 kg, puis 1001 kg, puis 1002 kg, pour voir à quel moment il casse.

🚀 Comment ça marche en pratique ?

1. Modélisation : GPU-Fuzz apprend les règles de chaque "ouvrier" (opérateur) de l'usine. Par exemple, pour un outil qui étire une image, il apprend : "Si l'image fait 100 pixels de large, l'étirement ne peut pas dépasser 50 pixels, sinon on sort du cadre."
2. Génération de cas tests : Il demande à son cerveau mathématique : "Donne-moi une situation où l'image fait 99 pixels et l'étirement 51 pixels." C'est une situation bizarre, mais mathématiquement possible.
3. L'expérimentation : Il lance cette situation bizarre sur les vrais robots (PyTorch, TensorFlow, PaddlePaddle) et regarde ce qui se passe avec une loupe très puissante (un outil appelé compute-sanitizer).
4. La découverte : Souvent, le robot panique, écrit dans la mauvaise mémoire, ou plante. GPU-Fuzz note l'erreur.

🏆 Les résultats : 13 failles trouvées !

En utilisant cette méthode, les chercheurs ont trouvé 13 bugs cachés dans les plus grands logiciels d'IA du monde.

• Certains bugs faisaient planter le logiciel (ce qui est visible).
• D'autres étaient silencieux : le logiciel continuait de tourner, mais il corrompait les données en secret. C'est comme si un cuisinier mettait du poison dans la sauce, mais que le client ne s'en rendait compte qu'après avoir mangé. C'est le type d'erreur le plus dangereux.

💡 Pourquoi c'est important ?

Aujourd'hui, l'IA est partout : voitures autonomes, diagnostics médicaux, banques. Si un robot dans ces usines fait une erreur de mémoire, cela peut avoir des conséquences graves (un accident de voiture, un faux diagnostic médical).

GPU-Fuzz nous apprend qu'il ne suffit pas de tester si l'IA "répond bien" aux questions. Il faut aussi vérifier si les outils internes de l'IA sont solides, même dans les situations les plus étranges et improbables.

En résumé :
GPU-Fuzz est comme un inspecteur de chantier qui ne regarde pas si le bâtiment est beau, mais qui vérifie méticuleusement si chaque vis, chaque poutre et chaque angle tient bon, même sous des conditions extrêmes, pour éviter que tout ne s'effondre un jour.

Résumé technique

1. Problématique

Les frameworks d'apprentissage profond (Deep Learning - DL) modernes comme PyTorch, TensorFlow et PaddlePaddle reposent massivement sur des GPU pour leurs calculs. Cependant, la correction de ces calculs est souvent menacée par des corruptions de mémoire au niveau des noyaux CUDA (kernels) de bas niveau.

Ces erreurs, telles que les accès hors limites (out-of-bounds) ou les adresses mémoire non alignées, peuvent entraîner :

• Des plantages système.
• Des corruptions de données silencieuses (silent data corruption) : le programme ne plante pas mais produit des résultats incorrects, ce qui est particulièrement dangereux pour les applications critiques (santé, conduite autonome).
• Des vulnérabilités de sécurité exploitables (attaques ROP, modification de code).

Limites des approches existantes : Les fuzzeurs actuels pour les systèmes DL (comme NNSmith) se concentrent principalement sur la génération de réseaux de neurones variés pour tester les compilateurs et détecter des erreurs arithmétiques. Ils négligent l'espace des paramètres des opérateurs individuels, où résident la plupart des bugs de mémoire. Ils n'explorent pas systématiquement les combinaisons de formes de tenseurs, de types de données, de strides (pas) et de remplissages (padding) qui déclenchent des conditions limites dangereuses dans les kernels CUDA.

2. Méthodologie : GPU-Fuzz

L'approche proposée, GPU-Fuzz, opère un changement de paradigme en passant d'une fuzzing au niveau du modèle de réseau à un fuzzing au niveau de l'opérateur. Le système repose sur trois phases principales :

A. Modélisation des Opérateurs

GPU-Fuzz modélise les opérateurs DL (convolution, pooling, etc.) via une couche d'abstraction qui capture leurs espaces de paramètres et leurs relations de forme.

• Les sémantiques des opérateurs sont traduites en formules de contraintes formelles utilisant des variables symboliques.
• Exemple : Pour une convolution, la relation entre la taille d'entrée ($H_{in}$), le padding ($P$), le noyau ($K$), le stride ($S$) et la sortie ($H_{out}$) est modélisée mathématiquement.
• Les auteurs ont manuellement extrait 45 contraintes pour 13 familles d'opérateurs, garantissant la validité sémantique des tests générés.

B. Génération de Cas de Test Guidée par Contraintes

Une fois les opérateurs modélisés, GPU-Fuzz utilise un solveur SMT (Z3) pour générer des cas de test.

• Exploration de l'espace paramétrique : Contrairement aux solveurs standards qui renvoyent souvent une seule solution de bordure, GPU-Fuzz utilise une stratégie de recherche itérative.
• Stratégie d'exclusion : À chaque itération, le système sélectionne aléatoirement un paramètre, ajoute une contrainte pour exclure sa valeur actuelle (et des valeurs similaires via des contraintes basées sur le hachage), et relance le solveur. Cela force l'exploration de régions non testées de l'espace des paramètres.
• Diversité : L'utilisation de contraintes de hachage ($h(x) \neq h(valeur)$) empêche le solveur de retourner des solutions trop similaires, augmentant la diversité des cas de test.

C. Exécution Multi-Frameworks et Détection

Les paramètres abstraits générés sont traduits en appels d'API concrets pour PyTorch, TensorFlow et PaddlePaddle.

• Chaque exécution est enveloppée par NVIDIA Compute Sanitizer, un outil de débogage de mémoire bas niveau.
• Si Compute Sanitizer détecte une erreur (accès hors limites, écriture non alignée, etc.), le journal d'exécution est archivé pour reproduction.

3. Contributions Clés

1. Nouvelle approche de fuzzing : Identification de l'espace des paramètres des opérateurs comme une dimension critique, orthogonale aux fuzzers existants basés sur la structure du réseau.
2. Conception de GPU-Fuzz : Un système automatisé utilisant la résolution de contraintes pour générer des tests ciblant spécifiquement les conditions limites de mémoire dans les kernels CUDA.
3. Découverte de bugs : Validation de l'efficacité de l'outil en découvrant des bugs inconnus dans des frameworks majeurs.

4. Résultats Expérimentaux

L'évaluation a été menée sur un serveur équipé d'un GPU NVIDIA H100, testant PyTorch, TensorFlow et PaddlePaddle.

• Découverte de Bugs : GPU-Fuzz a identifié 13 bugs inconnus (0-day).

  • Types de bugs : 7 violations d'accès mémoire (dont 5 corruptions silencieuses détectables uniquement par des outils bas niveau), des exceptions au niveau GPU (CUBLAS, cuDNN), et des assertions côté CPU (débordements d'entiers).
  • Opérateurs touchés : Principalement des convolutions transposées, des pooling adaptatifs et des opérations de padding.
  • Cause racine fréquente : Calculs incorrects des dimensions de la grille (grid dimensions) ou vérifications de limites défectueuses dans le code CUDA, souvent déclenchées par des combinaisons de paramètres extrêmes (ex: grands strides, grandes dimensions).

• Comparaison avec l'état de l'art (NNSmith) :

  • Sur une période de 4 heures, GPU-Fuzz a généré environ 51 860 cas de test (contre ~19 000 pour NNSmith).
  • Efficacité sur les bugs de mémoire : GPU-Fuzz a trouvé 26 ± 5 erreurs de mémoire critiques. À l'inverse, NNSmith n'en a trouvé aucune, se concentrant principalement sur des incohérences numériques ou des exceptions de configuration.
  • Cela démontre que GPU-Fuzz comble un angle mort majeur dans les tests de sécurité des GPU.

• Étude de cas (Proof of Concept) :

  • Un bug critique a été trouvé dans ConvTranspose2d de PyTorch. Une combinaison de paramètres (stride de 200, dimensions d'entrée massives) a provoqué un débordement d'entier lors du passage d'un entier 64-bit à 32-bit dans le code hôte. Cela a entraîné un calcul de grille sous-dimensionné, causant des écritures hors limites en mémoire globale, détectées par Compute Sanitizer.

5. Signification et Impact

• Sécurité de l'IA : Ce travail met en lumière que la sécurité des systèmes d'IA ne dépend pas seulement de la logique du modèle, mais aussi de la robustesse des implémentations de bas niveau des opérateurs. Les corruptions silencieuses sont une menace majeure pour la fiabilité des applications critiques.
• Complémentarité : GPU-Fuzz ne remplace pas les fuzzers de modèles (comme NNSmith) mais les complète. Une stratégie de sécurité complète doit combiner la vérification de l'arithmétique (niveau modèle) et la vérification de la sécurité mémoire (niveau opérateur/paramètre).
• Responsabilité : Tous les bugs découverts ont été divulgués de manière responsable aux équipes de développement des frameworks concernés, plusieurs ayant déjà été confirmés ou corrigés.

En conclusion, GPU-Fuzz démontre que l'exploration systématique et contrainte de l'espace des paramètres des opérateurs est une méthode puissante et nécessaire pour sécuriser les infrastructures d'apprentissage profond contre des vulnérabilités de mémoire subtiles et dangereuses.