GitSpawn : un dépôt malveillant exécute du code via les agents IA

Technique · Atelier

Comment eBPF s’installe dans la boucle io_uring

Depuis la fenêtre de merge du noyau 7.1, io_uring n’est plus seulement une file asynchrone partagée : un programme BPF peut remplacer l’étape de boucle qui suit io_uring_enter(). Voici ce que cela change pour qui écrit des runtimes I/O haute perf.

Rappel : io_uring expose deux anneaux en mémoire partagée — la submission queue (SQ) pour envoyer des requêtes au noyau, la completion queue (CQ) pour récupérer les résultats. L’espace utilisateur prépare des SQE, puis appelle io_uring_enter() (ou laisse un thread SQPOLL scruter). Même avec le partage mémoire, chaque aller-retour vers l’userspace pour enchaîner le travail après une completion coûte cher. Les chaînes linéaires (IOSQE_IO_LINK, drain, etc.) couvrent une partie des cas ; dès qu’il faut une logique un peu plus riche — décider du prochain lot selon le contenu d’une CQE — on repasse en userspace.

Le patch set de Pavel Begunkov, accepté par Jens Axboe le 17 mars 2026 (récit LWN), attache un struct_ops eBPF nommé io_uring_bpf_ops à un anneau. Au lieu de la boucle native, le callback loop_step est invoqué. Depuis ce callback, deux kfuncs comptent : bpf_io_uring_submit_sqes() pour pousser des SQE déjà écrites dans la région partagée, et bpf_io_uring_get_region() pour obtenir un pointeur borné vers les régions paramètres, SQ ou CQ sous contraintes du vérificateur. Le programme renvoie IOU_LOOP_CONTINUE (relancer après délai ou N completions) ou IOU_LOOP_STOP (rendre la main à l’userspace). En théorie, une appli peut monter l’anneau, enregistrer le BPF, appeler io_uring_enter() une fois… et ne plus jamais revenir.

Contraintes d’installation (code actuel) : l’anneau doit être créé avec IORING_SETUP_DEFER_TASKRUN ; SQPOLL et IOPOLL sont refusés ; un seul bpf_ops par anneau, lié au ring_fd. Le programme doit tolérer wake-ups parasites et annulation (signal / kill). Ce n’est pas un « plugin I/O illimité » : la surface est volontairement étroite.

Deuxième mécanisme, orthogonal : IORING_REGISTER_BPF_FILTER installe des filtres cBPF (pas eBPF) par opcode pour admettre ou refuser une soumission (-EACCES) avant mise en file — prédicat d’admission, contexte fixe (user_data, opcode, flags, PDU pour SOCKET/OPENAT/CONNECT). Hiérarchie utile : restrictions statiques IORING_RESTRICTION_* (enveloppe), filtre cBPF (prédicat), LSM hôte (autorité système), puis eBPF struct_ops (politique d’exécution dans la boucle). Les analyses Eunomia (2026) insistent : le filtre n’est pas « où eBPF entre dans io_uring » — la frontière profonde est le struct_ops.

Pourquoi ça compte pour le développeur système : FUSE-over-io_uring, réception zero-copy TCP dans des buffers enregistrés, ublk — l’anneau devient frontière d’exécution, pas seulement un batch de syscalls. Mettre de la logique dans BPF évite des context switches, mais complique le debug (un strace voit surtout un enter bloqué ; perf sur io_uring:* aide) et l’audit (qui a soumis la SQE — userspace ou boucle BPF ?). Alternative Ming Lei (IORING_OP_BPF) reste plus ciblée ; Axboe a d’abord mergé Begunkov. Pour expérimenter : libbpf + BTF vmlinux, anneau DEFER_TASKRUN, un loop_step minimal qui submit puis STOP — puis monter en complexité sans élargir la capacité au-delà de ce que LSM et les restrictions autorisent.

Sources : LWN, « BPF comes to io_uring at last », 18.03.2026 · Eunomia, « How Far Can eBPF Programmability Move Into io_uring? » · eBPF Docs, struct_ops / io_uring_bpf_ops (v7.1)