BCC et libbpf : construire ses propres outils eBPF

Deux bibliothèques dominent l'écriture d'outils eBPF : BCC, taillée pour prototyper vite, et libbpf, taillée pour distribuer un binaire portable. Choisir la bonne dès le départ évite de tout réécrire plus tard. Cette page montre BCC en action avec ses dizaines d'outils prêts à l'emploi, puis le workflow libbpf avec son squelette généré, et donne une règle de décision claire. Les sorties viennent d'une VM Ubuntu 24.04 (noyau 6.8, BCC 0.29.1). Pour le concept de portabilité sous-jacent, voir CO-RE et BTF.

Ce que vous allez apprendre

Utiliser les outils eBPF packagés de BCC sans écrire une ligne
Situer BCC (prototypage) face à libbpf (production)
Comprendre le workflow libbpf : objet compilé, squelette, chargeur
Décider quelle bibliothèque adopter selon votre besoin
Éviter de recommencer à zéro en choisissant mal au départ

Prérequis

Une VM Linux avec la chaîne d'outils eBPF (voir premier programme).
Les paquets bpfcc-tools (outils BCC) et libbpf-dev (bibliothèque libbpf), plus bpftool.

BCC : prototyper vite, et des outils tout faits

BCC (BPF Compiler Collection) est une bibliothèque qui laisse écrire le programme eBPF en C, embarqué dans un script Python (ou C++) qui pilote sa compilation, son chargement et l'affichage. Son atout : l'immédiateté. On écrit, on lance, ça marche. C'est l'outil idéal pour apprendre et pour répondre vite à une question ponctuelle.

BCC brille aussi par sa collection d'outils prêts à l'emploi, installés avec bpfcc-tools : des dizaines de diagnostics couvrant processus, fichiers, disque, réseau. Pas besoin de coder, ils sont là. Exemple, execsnoop affiche chaque nouveau processus lancé, avec sa lignée et ses arguments :

sudo execsnoop-bpfcc

Sortie réelle :

PCOMM            PID     PPID    RET ARGS
uname            24635   24616     0 /usr/bin/uname -r
id               24636   24616     0 /usr/bin/id -u
sleep            24637   24616     0 /usr/bin/sleep 0.25
uname            24638   24616     0 /usr/bin/uname -r

Chaque colonne parle : le nom du programme (PCOMM), son PID, le PID de son parent (PPID), le code de retour (RET) et la commande complète (ARGS). Quelques outils du même paquet, à connaître :

Outil	Ce qu'il montre
`execsnoop-bpfcc`	Chaque nouveau processus lancé
`opensnoop-bpfcc`	Chaque fichier ouvert, par qui
`biolatency-bpfcc`	Distribution des latences disque (histogramme)
`tcplife-bpfcc`	Durée de vie et volume de chaque connexion TCP
`runqlat-bpfcc`	Temps d'attente des processus avant de tourner

libbpf : compiler une fois, distribuer un binaire

libbpf est la bibliothèque C officielle du projet noyau. Avec elle, on écrit le programme eBPF en C, on le compile une seule fois en un objet, et un programme de chargement (en C, Rust, Go...) l'embarque. Combinée à CO-RE, elle produit un binaire portable qui tourne sur des noyaux différents sans recompilation, comme détaillé dans CO-RE et BTF.

Le confort de libbpf tient à un générateur : à partir de l'objet compilé, bpftool produit un squelette (skeleton), un en-tête C qui expose proprement les maps, les programmes et les accroches. On génère l'objet puis son squelette :

clang -O2 -g -target bpf -c ok.bpf.c -o ok.bpf.o
sudo bpftool gen skeleton ok.bpf.o > ok.skel.h

Extrait réel du squelette généré :

/* THIS FILE IS AUTOGENERATED BY BPFTOOL! */
struct ok_bpf {
  struct bpf_object_skeleton *skeleton;
  struct bpf_object *obj;
  struct {
    struct bpf_map *compteur;
  } maps;
  struct {
    struct bpf_program *deref_avec_test;
  } progs;
  struct {
    struct bpf_link *deref_avec_test;
  } links;

Le chargeur inclut ce fichier et manipule des champs nommés (obj->maps.compteur, obj->progs.deref_avec_test) au lieu de chaînes de caractères et de recherches manuelles. Le code de chargement devient court et sûr. C'est le modèle des outils eBPF modernes (Cilium, Tetragon, la suite bcc/libbpf-tools).

bpftrace, BCC ou libbpf : la règle de décision

Trois outils permettent d'écrire de l'eBPF, du plus simple au plus complet. Le tableau suivant les départage d'un coup d'œil, en y ajoutant bpftrace, qui répond à une bonne partie des besoins sans écrire de programme.

Critère	bpftrace	BCC	libbpf + CO-RE
Objectif	Question ponctuelle, one-liner	Apprendre, prototyper un outil	Distribuer un outil de production
Écrit-on du C ?	Non (langage dédié)	Oui (C dans Python)	Oui (C + chargeur)
Compilation	à chaque exécution	sur chaque cible, à chaque lancement	une seule fois
Dépendances sur la cible	bpftrace	clang + en-têtes noyau	aucune (juste le BTF)
Portabilité entre noyaux	recompile localement	recompile localement	binaire portable (CO-RE)
Quand l'utiliser	investigation rapide	apprentissage, prototype	déploiement à grande échelle

La règle tient en une phrase : bpftrace pour une réponse immédiate, BCC pour explorer et apprendre, libbpf pour livrer. On passe naturellement de l'un à l'autre le long du cycle de vie d'un outil : une idée testée en bpftrace, prototypée en BCC, puis réécrite en libbpf le jour où il faut la déployer partout.

Sécurité et points de vigilance

Charger reste privilégié. Quelle que soit la bibliothèque, il faut root ou CAP_BPF + CAP_PERFMON. Réservez ces outils aux administrateurs.
Ne pas embarquer clang en production pour BCC. Si un outil BCC doit tourner sur beaucoup de machines, c'est le signal qu'il faut passer à libbpf : on évite d'installer un compilateur sur chaque serveur.
Vérifier la présence du BTF pour CO-RE. libbpf + CO-RE exige /sys/kernel/btf/vmlinux sur la cible. Sur un noyau ancien qui en est dépourvu, prévoyez un BTF externe ou la recompilation.
Épingler ce qui doit survivre. Un outil libbpf peut épingler ses maps dans /sys/fs/bpf pour qu'elles persistent ; c'est un partage de données à protéger.

À retenir

BCC écrit le programme en C dans un script Python, compile sur la cible, et livre des dizaines d'outils prêts à l'emploi (execsnoop, opensnoop...).
libbpf compile une seule fois et, avec CO-RE, produit un binaire portable sans dépendances sur les cibles.
Le squelette généré par bpftool rend le code de chargement libbpf court et sûr.
Règle : BCC pour explorer, libbpf pour livrer ; on passe souvent de l'un à l'autre.
Les libbpf-tools offrent des diagnostics tout faits, mais en version portable et légère.
Dans tous les cas, charger de l'eBPF reste une opération privilégiée.

Prochaines étapes

CO-RE et BTF : un binaire portable Le mécanisme qui rend un outil libbpf portable entre noyaux.

bpftrace : tracer le noyau en une ligne La voie la plus rapide quand il n'y a pas d'outil packagé.

Inspektor Gadget : eBPF pour Kubernetes Les outils BCC/libbpf orchestrés à l'échelle d'un cluster.