Les ingénieurs utilisent eBPF pour inspecter le comportement du noyau Linux sans modules du noyau

Dan Fineran, principal community advocate chez Isovalent chez Cisco, a déclaré à InfoQ que les développeurs utilisent désormais eBPF bien au-delà du filtrage des paquets, avec des équipes qui l’appliquent à l’observabilité Linux, au réseau Kubernetes, à l’application des syscalls et à de premières expérimentations sous Windows.

Les développeurs du noyau ont créé eBPF à partir de l’ancien modèle Berkeley Packet Filter. Le BPF d’origine offrait aux administrateurs un moyen de filtrer les paquets. eBPF a conservé l’idée de petits programmes attachés à des hooks du noyau, puis a étendu le modèle en une couche d’extension plus large.

Fineran a expliqué que l’attrait commence par le chemin de contribution à Linux. Une équipe qui souhaite un nouveau comportement du noyau peut écrire un correctif, solliciter des revues auprès des mainteneurs du sous-système, attendre son intégration au noyau, puis attendre à nouveau que des distributions comme Ubuntu ou Red Hat livrent ce noyau. Ce parcours protège les utilisateurs de Linux, mais il ralentit les équipes qui ont besoin dès maintenant d’une visibilité ou d’un mécanisme d’application en production.

Les équipes peuvent aussi écrire des modules du noyau, mais cette voie entraîne un couplage aux versions et un risque de plantage. L’auteur d’un module compile souvent contre une version précise du noyau. Un mauvais code de module peut bloquer l’exécution ou faire planter un hôte. eBPF offre aux développeurs une cible plus réduite avec des garde-fous plus solides.

Le garde-fou que Fineran a souligné est le vérificateur. Les développeurs compilent le code eBPF en bytecode, puis demandent au noyau de le charger. Le vérificateur contrôle les accès mémoire, les bornes des boucles et le comportement du programme avant que le noyau n’accepte le programme. S’il détecte un accès dangereux ou un chemin d’exécution qui peut s’exécuter sans limite, il refuse le programme.

Ce modèle offre aux ingénieurs plateforme un moyen de déployer à chaud un comportement au niveau du noyau. Vous pouvez attacher du code à des hooks pris en charge sur un système en cours d’exécution et le retirer sans reconstruire le noyau. Il faut toujours une compétence de bas niveau, souvent en C et désormais plus souvent avec des outils Rust, mais on évite le profil de risque opérationnel d’un module du noyau complet.

Fineran a également rejeté l’idée que les développeurs doivent apprendre eBPF avant de pouvoir utiliser des outils fondés sur eBPF. Cilium, le projet de réseau Kubernetes d’Isovalent, masque une grande partie de cette mécanique derrière des abstractions de politique et de service. Les opérateurs définissent quels workloads peuvent communiquer entre eux. Les ingénieurs de Cilium utilisent eBPF sous le capot pour acheminer les paquets et appliquer les politiques.

Le même schéma s’applique à Tetragon, qu’Isovalent a conçu pour la sécurité et l’observabilité à l’exécution. Les équipes de sécurité peuvent utiliser les politiques de Tetragon sans écrire de programmes eBPF bruts. Tetragon s’attache aux syscalls et à d’autres hooks du noyau, enregistre l’activité et peut bloquer des actions spécifiques avant que le noyau ne les exécute.

Ce modèle pré-hook change les opérations de sécurité. Un agent traditionnel peut enregistrer une suppression de fichier ou une élévation de privilèges après que le noyau a exécuté l’action. Avec eBPF, une équipe de sécurité peut placer de la logique avant un syscall et arrêter l’opération. Fineran a donné des exemples comme bloquer des suppressions dans un répertoire de projet protégé, limiter l’accès aux fichiers de base de données au démon de base de données, ou empêcher une élévation de privilèges hors des chemins approuvés.

Les ingénieurs peuvent aussi utiliser les politiques Tetragon pour atténuer des schémas de vulnérabilité connus. Si une équipe sait qu’une fonction vulnérable traite mal les entrées au-delà d’une certaine taille, elle peut attacher une politique avant le chemin vulnérable et rejeter les entrées qui correspondent au schéma d’exploitation. Cela ne remplace pas la correction, mais cela donne aux équipes d’exploitation un moyen de réduire l’exposition pendant que les responsables applicatifs préparent des correctifs permanents.

Fineran a relié le même mécanisme à l’observabilité. Les développeurs peuvent attacher des programmes à des probes noyau, des probes de retour, des tracepoints, des syscalls et des probes côté espace utilisateur. Cela donne aux équipes une visibilité sur l’accès aux fichiers, les appels réseau, les appels de bibliothèque, les chemins de stockage et le comportement des pilotes, sans ajouter de bibliothèques d’instrumentation à chaque application.

L’utilisation du GPU a fourni un exemple. Fineran a décrit des équipes qui attachent des programmes eBPF près des chemins du pilote NVIDIA CUDA pour lire l’activité de bas niveau et la corréler avec la demande des workloads. Les équipes plateforme peuvent utiliser ce signal pour maintenir les accélérateurs coûteux occupés et réduire la capacité gaspillée.

Les développeurs doivent toutefois comprendre les limites. Le vérificateur restreint la taille des programmes, le comportement des boucles et les accès mémoire. Les messages d’erreur peuvent déstabiliser les nouveaux utilisateurs, surtout lorsque le vérificateur renvoie des diagnostics denses. Fineran a indiqué que la communauté a amélioré les outils et la documentation, notamment Learning eBPF de Liz Rice et les ressources de la communauté eBPF.

Microsoft a également ouvert une voie pour eBPF sous Windows via le projet eBPF for Windows. Les utilisateurs Linux bénéficient du support eBPF dans le noyau, tandis que les utilisateurs Windows ont encore besoin de pilotes supplémentaires. Fineran a déclaré que cette orientation multiplateforme pourrait aider les organisations à unifier l’observabilité et les politiques sur des systèmes d’exploitation mixtes.

La conversation a aussi porté sur les micro-VM et l’isolation Kubernetes. Fineran a indiqué que les équipes peuvent combiner l’isolation du noyau avec des contrôles d’exécution fondés sur eBPF. Les micro-VM réduisent le risque lié au partage du noyau, tandis que Tetragon peut toujours inspecter et appliquer des règles au sein des environnements invités pris en charge. Edera, a-t-il dit, a ajouté la prise en charge d’eBPF à l’intérieur de son noyau de micro-VM.

Les opérations pilotées par l’IA ont été évoquées comme une voie future. Fineran a dit que Cisco et la communauté ont expérimenté des politiques Tetragon générées par modèle, bien que les modèles actuels puissent produire des champs de politique qui semblent plausibles et échouent à la validation. Il a décrit un flux de travail probable dans lequel un outil de vulnérabilité identifie une forme d’exploitation, un modèle rédige une politique, et un système de validation humain ou automatisé teste la politique avant son déploiement.

Ce flux de travail exige une revue. Fineran a averti que les utilisateurs open source devraient examiner la solidité des mainteneurs, la cadence des mises à jour, la profondeur du support et la provenance du code avant d’adopter des projets eBPF. Le code généré par l’IA peut augmenter le volume de contributions, mais les responsables du projet doivent toujours disposer d’une compréhension suffisante pour corriger les bogues, soutenir les utilisateurs et maintenir le projet après des changements de modèle ou d’outillage.

Pour la plupart des développeurs, eBPF restera un détail d’implémentation à l’intérieur d’outils tels que Cilium et Tetragon. Pour les équipes plateforme, sécurité et observabilité, il offre un moyen direct d’inspecter et de façonner le comportement du système à la frontière du noyau, sans livrer de modules du noyau ni attendre des changements en amont du noyau.