Aller au contenu

Berkeley Packet Filter

Un article de Wikipédia, l'encyclopédie libre.
Page d’aide sur l’homonymie

Pour les articles homonymes, voir filtre et BPF.

Le BPF (Berkeley Packet Filter ou BSD packet filter), désigne un programme injecté depuis l'espace utilisateur, généralement dans un noyau de système d'exploitation de type Unix, permettant notamment d'effectuer du filtrage réseau.

On distingue l'implémentation initiale, parfois nommée cBPF pour classical BPF, qui désigne un programme minimaliste limité au filtrage de paquets réseau dans le noyau, et sa ré-implémentation moderne nommée eBPF pour extended BPF, autorisant des programmes plus complexes et dont les cas d'usages ne se limitent pas à l'interception de paquets réseau. eBPF est intégré depuis 2013 au noyau Linux[1]. Il existe un portage pour Microsoft Windows[2], et un autre en cours d'implémentation pour FreeBSD[3]. Le terme BPF peut désigner cBPF comme eBPF, selon le contexte[4].

Différents problèmes existent encore à ce jour, principalement au niveau du vérificateur[Lesquels ?].

Historique

[modifier | modifier le code]

BPF signifie à l'origine BSD packet filter, développé pour UNIX en 1992 par Steven McCanne et Van Jacobson au Laboratoire national Lawrence-Berkeley, afin de capturer des paquets réseau depuis l’espace utilisateur via l'injection de filtres dans le noyau de système d'exploitation, conçus comme des programmes minimalistes[5],[6],[7]. Ils permettent alors une amélioration de performances dans les applications d'analyse réseau tel que tcpdump, en évitant la copie de l'intégralité des paquets depuis l'espace noyau vers l'espace utilisateur[7],[8],[9],[10],[11].

À l’origine les BPF n’ont pas pour fonction de jeter des paquets reçus, mais décrits comme filtres ils peuvent associer des paquets, copier des paquets, et envoyer des paquets[12]. Initialement les BPF sont implémentés dans le noyau Linux 2.x, disposant de 2 registres 32 bits[13],[14],[15],[8]. Toutefois, de par leur côté minimaliste ils possèdent peu d’instructions, et leur difficulté de programmation fait qu’ils ne sont utilisés que par un petit nombre d’applications telles que tcpdump[10],[11].

En 2013, Alexei Starovoitov, alors ingénieur logiciel chez PLUMgrid[1], refaçonne complètement BPF en y ajoutant de nouvelles fonctionnalités et en améliorant ses performances. Avec Daniel Borkmann, alors ingénieur chez Red Hat, ils intègrent cette implémentation dans le noyau Linux, remplaçant la précédente[16]. Cette nouvelle version est appelée eBPF (extended BPF), et la version antérieure sera rétrospectivement appelée cBPF (classical BPF). eBPF permet de concevoir une plus grande variété de cas d’utilisation, notamment dans le traçage d'événements du noyau, la supervision du trafic réseau, la programmation réseau, la sécurité, etc[4],[9]. Parmi les changements les plus notables figure le passage à 10 registres de 64 bits[13],[14],[15],[8], l’appel de fonction dans le kernel grâce à une nouvelle instruction[15],[14],[8], ou encore l'ajout de structures de données telles qu'un ringbuffer et des maps, lesquelles autorisent une persistance d'état[17] qui était impossible précédemment.

logo de l'eBPF représentant une abeille et les lettres eBPF
le logo de l' eBPF, acronyme de (en) extended Berkeley Packet Filter

eBPF fait son apparition dans la version 3.18 du noyau Linux[15],[13],[18], avec des améliorations continues telles qu’un compilateur JIT (Just In Time)[6],[9], de nouvelles fonctionnalités telles que les maps et les tail calls[9]. Les programmes eBPF peuvent s'injecter de différentes manières : via des points d'attache pré-définis (tracepoints)[19], les kprobes du noyau Linux (ou leur version améliorée en 2019, fentry/fexit[20]) ou des uprobes de l'espace utilisateur[21]. Ces dernières permettent par exemple l'accès "en clair" aux paquets chiffrés via une attache dans la bibliothèque OpenSSL[22]. En 2015 et 2016, les possiblités d'attache se sont étoffées, d'abord avec le traffic controller en entrée comme en sortie, puis avec XDP[23],[24],[25].

Les programmes eBPF sont vérifiés et volontairement restreints de différentes manières, notamment quant au nombre d'instructions autorisées. En 2019, certaines restrictions sont levées : la limite du nombre d'instructions totales disparait, et la limite du nombre d'instructions vérifiées (complexité) passe de 32768 à 1 million[26].

Un documentaire sur YouTube retrace, avec les auteurs des premiers commits, la genèse de eBPF[27] entre 2013 et 2023.

Écosystème

[modifier | modifier le code]

Un écosystème d'outils et de bibliothèques s'est constitué autour de la technologie. libbpf est une bibliothèque C permettant de vérifier et charger dans le noyau des objets BPF compilés, en les attachant aux hooks désirés. Elle offre des helpers facilitant la programmation de code eBPF, ainsi que la fonctionnalité CO-RE (Compile Once – Run Everywhere) permettant une portabilité des programmes BPF indépendamment de la version du noyau Linux sur lequel ils s'exécutent. bcc (BPF Compiler Collection) permet d'écrire des programmes eBPF avec un backend en C et un frontend en Python ou Lua[28]. D'autres bibliothèques offrent un support d'eBPF dans d'autres langages, telles que gobpf et ebpf-go en Go, ou Aya en Rust.

Parmi les outils les plus répandus, bpftrace permet d'écrire des scripts traduits en BPF parfois via de simples one-liners, et bpftool permet d'inspecter et manipuler les programmes BPF chargés dans le système.

Cas d'utilisation

[modifier | modifier le code]

Il existe de multiples cas d'utilisation tel que du traçage (exemple : ply), de l'observabilité (exemples : Hubble, kepler), du filtrage pare-feu, de la mise en réseau de conteneurs[10] (exemple : Cilium (en)), du filtrage de socket, du filtrage de paquet et du contrôle de trafic[6], de la détection d'intrusion (exemples : suricata, falco), etc.

Il est également possible de faire du filtrage au plus bas niveau de la pile réseau, c’est-à-dire directement par le pilote de la carte d’interface réseau. Ainsi des paquets peuvent être jetés ou redirigés très tôt; par exemple XDP (Express Data Path) est un type de point d'attache eBPF utilisable entre autres pour la prévention d’attaque par déni de service[6].

De plus, les BPF permettent de faire de la surveillance efficace et flexible des performances d’un réseau pour des applications dans des machines virtuelles, un exemple est le framework vNetTracer[11].

La variété de cas d'utilisation rapproche eBPF des modules noyau qui peuvent être utilisés à des fins similaires, mais en comparaison, eBPF offre des avantages en matière de sécurité et de maintenance[29], un programme BPF ne pouvant en théorie pas provoquer d'erreur fatale dans le noyau, et ne nécessitant pas de recompilation pour toute nouvelle version du noyau.

Fonctionnement technique

[modifier | modifier le code]

BPF utilise des graphes de flot de contrôle (CFG) afin de représenter les critères utilisés dans l'analyse de paquets, et aussi pour sa performance sur les expressions de modèle d’arbre[30],[12]. Ces graphes sont utilisés par BPF pour mettre en place des règles de filtrage permettant de réduire efficacement les chemins CFG inutiles à l'analyse d'un paquet ainsi que les comparaisons redondantes[12],[13].

Le transfert de donnée fait par les appels systèmes se fait de manière bidirectionnelle entre le noyau et l'espace utilisateur. Ceux-ci permettant le bon déroulement de l'injection du code binaire d’eBPF dans le noyau ainsi que la communication des données du noyau cible vers un processus de l'espace utilisateur[31].

Dans l'implémentation cBPF, les paquets associés par le programme BPF sont en partie copiés dans un buffer avant d’être transférés dans l’espace utilisateur. BPF permet au programme de définir le nombre d’octets du paquet devant être copiés dans le buffer. Cela permet de faire des économies en temps en évitant de copier des données non nécessaires. Par exemple, pour les paquets TCP/IP/Ethernet, 134 octets suffisent. Un programme voulant faire des statistiques sur les trames TCP sera en mesure de copier seulement une partie des trames économisant ainsi du temps d’exécution[12].

Avec eBPF, le chargement des programmes est réalisé par l'utilisateur, et une vérification est faite sur la terminaison d'un programme afin de s'assurer que celui-ci est sûr à exécuter[32]. Plusieurs structures de données permettent de partager les informations non seulement entre l'espace noyau et l'espace utilisateur, mais également entre les invocations de programmes BPF (par exemple via différents points d'attache)[32]:

  • Le perf buffer est un tampon circulaire par cœur CPU. Un programme eBPF peut capturer des événements puis les enregistrer dans une structure C, qui sera alors envoyée dans ce tampon[33]. Le tampon peut être lu depuis l'espace utilisateur.
  • Le ring buffer[34] est également un tampon circulaire, mais il est global pour l'ensemble des cœurs CPU. Son fonctionnement est similaire au perf buffer.
  • Les maps : ce sont des structures de données permettant la persistance des données au cours de l’exécution d’un programme BPF, utilisées notamment pour l’agrégation de statistiques[33]. Plusieurs variantes existent[35] : globales ou par cœur CPU, indexées par valeur numérique ou par hachage, queues, piles, LRU, etc. Les maps peuvent être écrites depuis l'espace noyau et lues depuis l'espace noyau ou utilisateur. Des verrous peuvent être placés pour gérer les accès concurrents[36].
  • Le fichier /sys/kernel/debug/tracing/trace_pipe : Ce fichier peut être lu depuis l’espace utilisateur et écrit par un programme, mais son utilisation est fortement déconseillé car plusieurs traceurs écrivent dessus rendant la lecture incohérente[33].

Depuis la version 3.15 du noyau Linux les fonctions de la machine virtuelle de eBPF fournissent un accès à la couche liaison grâce à des instructions basiques et à l'introduction de nouvelles fonctionnalités d’eBPF, ceci permet de créer un moyen de filtrer et d’analyser les paquets du réseau[37]. Cependant les programmes eBPF peuvent être invoqués dans différentes couches de la pile réseaux ce qui permet de traiter les paquets capturés avant de progresser vers la couche suivante[13].

eBPF s’appuie sur un code binaire compilé en instructions natives du CPU au chargement de l'extension dans le noyau. Contrairement au bytecode classique comme Java par exemple, le compilateur et le temps d’exécution d’eBPF n’imposent pas de type ni de sécurité mémoire. Au lieu de cela, la sécurité est renforcée par un vérificateur statique qui vérifie que le programme ne peut pas accéder à des structures de données du noyau ou provoquer des erreurs de page[38].

Des risques de sécurité et de stabilité sont présents lorsqu'un code est exécuté dans le noyau. Pour pallier ces risques, cBPF compte sur un interpréteur pour exécuter sûrement un programme. Avec eBPF, un vérificateur est introduit pour s’assurer du respect de certaines conditions avant d’être chargé dans le noyau, évitant ainsi un fort coût en temps en vérification à l'exécution. Il s’assure que le programme est en mesure de se terminer, qu'il ne contient pas de boucle pouvant engendrer un blocage du kernel ou que certaines instructions soient inaccessibles. Il vérifie et simule chaque instruction afin d’être sûr que l’état des registres et des piles soient valides, empêchant ainsi l'accès à la mémoire ou à l’état du noyau hors de sa zone allouée[38],[15].

Plusieurs programmes eBPF peuvent être instanciés en parallèle, y compris sur les mêmes hooks. Ainsi ils peuvent opérer individuellement ou être chainés[réf. nécessaire]. Cela peut nécessiter une forme de coopération et de priorisation pour le chaînage de programmes. bpfman est un projet CNCF "sandbox" visant à faciliter cette coopération[39].

Réseaux

[modifier | modifier le code]

Un programme cBPF peut être en écoute sur une interface. Le pilote de l’interface fait alors appel à ce programme en premier. BPF distribue les paquets à chaque filtre qui participe au traitement. Les filtres définis par l'utilisateur s’appliquent aux paquets et décident si chaque paquet est accepté ou non, et combien d'octets de chaque paquet doivent être sauvegardés. Pour chaque filtre acceptant le paquet, BPF copie la quantité de données demandée que le buffer a associé à ce filtre[30].

Lorsque des modifications de topologies surviennent ou un changement dans les applications, il devient nécessaire de modifier les règles servant de pare-feu afin de pouvoir ajouter, supprimer ou modifier les ports et les adresses impactés par les filtres. Pour cela, grâce à la stratégie de bitmap, qui permet de garder le programme C simple, il suffit de créer un nouveau programme avec de nouvelles maps et de charger la map avec de nouvelles clés-valeur et de l'échanger avec l’ancien programme, imitant ainsi le comportement de iptables-restore[40].

Outils

[modifier | modifier le code]

Jit compiler

[modifier | modifier le code]

Les filtres sont interprétés sous forme de bytecode dans un kernel avec interpréteur. Dans le cas de l'absence de celui-ci, eBPF peut utiliser le compilateur à la volée du kernel (JIT compiler) afin de traduire les bytecodes produit par eBPF en code natif et de réaliser des optimisations optionnelles dépendant de la machine[41].

LLVM

[modifier | modifier le code]
Article principal : LLVM.

Clang (LLVM natif) permet à l’utilisateur de compiler son code C en instruction eBPF dans un fichier ELF[42].

BCC

[modifier | modifier le code]

La programmation en instruction eBPF peut être compliquée. C’est pour cela qu’un toolkit appelé BPF Compiler Collection (BCC) existe permettant à l’utilisateur de créer facilement des programmes eBPF. BCC englobe LLVM et l’améliore afin de fournir à l’utilisateur la possibilité de définir des eBPF maps dans un code C et de compiler ce code C en programme eBPF[33],[13],[37],[6].

Instructions

[modifier | modifier le code]

La machine virtuelle de BPF+ possède 5 classes d’opération :

  • load : copie une valeur dans un registre.
  • store : copie un registre à une position fixe dans la mémoire.
  • alu : opération arithmétique et logique.
  • branch : alter le flux de contrôle, basé sur une comparaison teste entre un registre et une valeur immédiate ou un autre registre.
  • return : termine le filtre et retourne le résultat de l'évaluation[41].

Limitations

[modifier | modifier le code]

Les programmes eBPF sont volontairement restreints afin de maintenir l'intégrité et la sécurité du système, via des contraintes imposées par le vérificateur, dont voici une liste non exhaustive :

  • le nombre d'instructions vérifiées ne peut dépasser 1 million[26].
  • les boucles infinies, ou la récursion infinie sont interdites[38],[26].
  • la lecture de zone mémoire arbitraire est interdite[43].
  • aucun espace utilisateur ou service tiers ne peut être utilisé dans les programmes eBPF[44].
  • impossibilité de faire des allocations dynamiques.
  • les programmes s'exécutent sur un seul thread et donc ont un temps d'exécution lié aux nombres d’instructions[38].

En 2019, il était fait état de nombreux faux positifs générés par le vérificateur[38][réf. obsolète].

Performance BPF

[modifier | modifier le code]

Les cBPF utilise une stratégie de mise en mémoire tampon qui rend sa performance totale jusqu’à 100 fois plus rapide que le NIT (Network Interface Tap (en)) de SUN s'exécutant sur le même matériel[30].

Le temps d'exécution d’un appel à BPF est d’environ 6 microseconde par paquet pour un filtre qui rejette tous les paquets[30].

Les eBPF sont jusqu'à 4 fois plus rapides sur les architecture x86_64 que l’implémentation des cBPF pour certain microbenchmark de filtrage réseaux, et la plupart sont 1.5 fois plus rapides[15].

Il existe un facteur 10 d’amélioration de performance des eBPF comparé aux IPTABLES et NFTABLES[6].

Express Data Path (XDP)

[modifier | modifier le code]

Un programme eBPF XDP est attaché au plus bas niveau de la pile réseau, avant tout traitement par le noyau. Il est adéquat pour le filtrage grossier de paquets tel que la prévention d'attaques par déni de service. Il peut produire quatre fois les performances en comparaison à une tâche similaire dans le kernel[6].

De plus, XDP offre des améliorations sur la latence médiane en utilisant le code compiler en JIT (Just In Time), jusqu'à 45% d’amélioration de performance avec comme coût une plus haute valeur de latence aberrantes[6].

XDP offre un compromis, il n’offre pas des performances aussi bonnes que les frameworks dédiés hautes performances qui outrepassent le noyau (DPDK (en), hardware offloading (en)). Cependant il offre une intégration au noyau, c’est-à-dire que les paquets peuvent passer par la pile réseau avec tous ses avantages. Bien qu’il traite seulement 50% du débit d’une ligne 10 GbE[pas clair], cela représente les performances d’un seul cœur, c’est-à-dire qu’il évolue avec le nombre de cœurs CPU[6][réf. obsolète].

Référence

[modifier | modifier le code]
  1. ↑ a et b (en) « eBPF Documentary: eBPF's Creation Story - Unlocking The Kernel », sur isovalent.com, (consulté le )
  2. ↑ microsoft/ebpf-for-windows, Microsoft, (lire en ligne)
  3. ↑ « eBPF Implementation for FreeBSD :: FreeBSD Presentations and Papers », sur papers.freebsd.org (consulté le )
  4. ↑ a et b (en) « What is eBPF? An Introduction and Deep Dive into the eBPF Technology », sur ebpf.io (consulté le )
  5. ↑ (en) Steven McCanne et Van Jacobson, « The BSD Packet Filter: A New Architecture for User-level Packet Capture » [PDF], (consulté le )
  6. ↑ a b c d e f g h et i Scholz 2018
  7. ↑ a et b Jouet 2015
  8. ↑ a b c et d Corbet 2014
  9. ↑ a b c et d Monnet 2016
  10. ↑ a b et c Chaignon 2018
  11. ↑ a b et c Suo 2018
  12. ↑ a b c et d Lidl 2002
  13. ↑ a b c d e et f Baidya 2018
  14. ↑ a b et c Jouet 2017
  15. ↑ a b c d e et f Fleming 2017
  16. ↑ « [PATCH net-next v4 0/9] BPF updates - Daniel Borkmann », sur lore.kernel.org (consulté le )
  17. ↑ Cilium Authors 2019
  18. ↑ « Linux_3.18 - Linux Kernel Newbies », sur kernelnewbies.org (consulté le )
  19. ↑ (en) « Program Type 'BPF_PROG_TYPE_TRACEPOINT' - eBPF Docs », sur docs.ebpf.io (consulté le )
  20. ↑ « Introduce BPF trampoline [LWN.net] », sur lwn.net (consulté le )
  21. ↑ (en) « Program Type 'BPF_PROG_TYPE_KPROBE' - eBPF Docs », sur docs.ebpf.io (consulté le )
  22. ↑ (en) « Debugging with eBPF Part 3: Tracing SSL/TLS connections », sur Pixie Labs Blog (consulté le )
  23. ↑ « [PATCH net-next v2 0/8] eBPF support for cls_bpf - Daniel Borkmann », sur lore.kernel.org (consulté le )
  24. ↑ « [PATCH net-next v2] net, sched: add clsact qdisc - Daniel Borkmann », sur lore.kernel.org (consulté le )
  25. ↑ « [PATCH v10 00/12] Add driver bpf hook for early packet drop and forwarding - Brenden Blanco », sur lore.kernel.org (consulté le )
  26. ↑ a b et c (en) « eBPF Updates #4: In-Memory Loads Detection, Debugging QUIC, Local CI Runs, MTU Checks, but No Pancakes », sur ebpf.io (consulté le )
  27. ↑ « eBPF: Unlocking the Kernel [OFFICIAL DOCUMENTARY] » (consulté le )
  28. ↑ « bcc: Taming Linux 4.3+ Tracing Superpowers », sur www.brendangregg.com (consulté le )
  29. ↑ (en-US) Rachel Stephens, « Why You Should Pay Attention to eBPF », sur Alt + E S V, (consulté le )
  30. ↑ a b c et d McCanne 1993
  31. ↑ Saif 2018
  32. ↑ a et b Ellis 2017
  33. ↑ a b c et d Belkalem 2018
  34. ↑ « BPF ring buffer — The Linux Kernel documentation », sur www.kernel.org (consulté le )
  35. ↑ (en) « Map Type 'BPF_MAP_TYPE_HASH' - eBPF Docs », sur docs.ebpf.io (consulté le )
  36. ↑ (en) « Concurrency - eBPF Docs », sur docs.ebpf.io (consulté le )
  37. ↑ a et b Nam 2017
  38. ↑ a b c d et e Gershuni 2019
  39. ↑ « Redirecting », sur bpfman.io (consulté le )
  40. ↑ Deepak 2018
  41. ↑ a et b Begel 1999
  42. ↑ Tu 2018
  43. ↑ (en) « Verifier - eBPF Docs », sur docs.ebpf.io (consulté le )
  44. ↑ Van Tu 2017

Bibliographie

[modifier | modifier le code]

Les références ci-dessus font éventuellement appel à la bibliographie ci-dessous.

  • (en) Justin Pettit, Joe Stringer et Cheng-Chun Tu, « Building an Extensible Open vSwitch Datapath », ACM SIGOPS Operating Systems Review,‎ (DOI 10.1145/3139645.3139657)
  • (en) Sebastiano Miano, Matteo Bertrone, Fulvio Risso, Massimo Tumolo et Mauricio Vásquez B, « Creating Complex Network Services with eBPF: Experience and Lessons Learned », 2018 IEEE 19th International Conference on High Performance Switching and Routing (HPSR),‎ (ISBN 978-1-5386-7802-2, ISSN 2325-5595, DOI 10.1109/HPSR.2018.8850758)
  • (en) Cynthia Sturton, Rohit Sinha et Thurston H. Y. Dang, « Symbolic software model validation », 2013 Eleventh ACM/IEEE International Conference on Formal Methods and Models for Codesign (MEMOCODE 2013),‎ (ISBN 978-1-4799-0903-2)
  • Document utilisé pour la rédaction de l’article(en) Steven McCanne et Van Jacobson, « The BSD Packet Filter: A New Architecture for User-level Packet Capture », USENIX'93 Proceedings of the USENIX Winter 1993 Conference Proceedings on USENIX Winter 1993 Conference Proceedings,‎
  • Document utilisé pour la rédaction de l’article(en) Dominik Scholz, Daniel Raumer, Paul Emmerich, Alexander Kurtz, Krzysztof Lesiak et Georg Carle, « Performance Implications of Packet Filtering with Linux eBPF », IEEE Xplore,‎ (ISBN 978-0-9883045-5-0, DOI 10.1109/ITC30.2018.00039)
  • (en) Suo Kun, Zhao Yong, Chen Wei et Rao Jia, « Demo/poster abstract: Efficient and flexible packet tracing for virtualized networks using eBPF », IEEE INFOCOM 2018 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS),‎ (ISBN 978-1-5386-5979-3, DOI 10.1109/INFCOMW.2018.8406849)
  • (en) Dominik Scholz, Daniel Raumer, Paul Emmerich, Alexander Kurtz, Krzysztof Lesiak et Georg Carle, « Performance Implications of Packet Filtering with Linux eBPF », 2018 30th International Teletraffic Congress (ITC 30),‎ , p. 209-217 (ISBN 978-0-9883045-5-0, DOI 10.1109/ITC30.2018.00039)
  • Document utilisé pour la rédaction de l’article(en) Abdulqawi Saif, Lucas Nussbaum et Ye-Qiong Song, « IOscope: A Flexible I/O Tracer for Workloads’ I/O Pattern Characterization », ISC High Performance,‎ , p. 14 (DOI 10.1007/978-3-030-02465-9_7)
  • Document utilisé pour la rédaction de l’article(en) Kun Suo, Yong Zhao, Wei Chen et Jia Rao, « vNetTracer: Efficient and Programmable Packet Tracing in Virtualized Networks », IEEE 38th International Conference on Distributed Computing Systems (ICDCS),‎ (DOI 10.1109/ICDCS.2018.00026)
  • (en) Zhenyu Wu, Mengjun Xie et Haining Wang, « Design and Implementation of a Fast Dynamic Packet Filter », IEEE/ACM Transactions on Networking, vol. 19,‎ , p. 1405 - 1419 (ISSN 1063-6692, DOI 10.1109/TNET.2011.2111381)
  • (en) Haina Tang, Lian Duan et Jun Li, « A performance monitoring architecture for IP videoconferencing », 2004 IEEE International Workshop on IP Operations and Management,‎ (ISBN 0-7803-8836-4, DOI 10.1109/IPOM.2004.1547591)
  • Document utilisé pour la rédaction de l’article(en) Paul Chaignon, Kahina Lazro, Jerome Francois, Thibault Delmas et Olivier Festor, « Oko: Extending Open vSwitch with Stateful Filters », ACM Symposium,‎ , p. 1-13 (DOI 10.1145/3185467.3185496)
  • (en) Ludwig Thomeczek, Andreas Attenberger et Johannes Kolb, « Measuring Safety Critical Latency Sources using Linux Kernel eBPF Tracing », ARCS Workshop 2019; 32nd International Conference on Architecture of Computing Systems,‎ (ISBN 978-3-8007-4957-7)
  • Document utilisé pour la rédaction de l’article(en) Xuan-Thuy Dang, Manzoor Ahmed Khan, Sebastian Peters et Tobias Dorsch, « Realization of handover management in SDNized 3GPP architecture with protocol independent forwarding », Innovation in Clouds Internet and Networks and Workshops (ICIN) 2019 22nd Conference,‎ , p. 277 - 284 (DOI 10.1109/WD.2018.8361695)
  • (en) Jose Fernando Zazo, Sergio Lopez-Buedo, Gustavo Sutter et Javier Aracil, « Automated synthesis of FPGA-based packet filters for 100 Gbps network monitoring applications », 2016 International Conference on ReConFigurable Computing and FPGAs (ReConFig),‎ (ISBN 978-1-5090-3707-0, DOI 10.1109/ReConFig.2016.7857156)
  • Document utilisé pour la rédaction de l’article(en) Scott Raynel, Anthony McGregor et Murray Jorgensen, « Using the IEEE 802.11 Frame Check Sequence as a pseudo random number for packet sampling in wireless networks », 2009 7th International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks,‎ , p. 850-855 (ISBN 978-1-4244-4919-4, DOI 10.1109/WIOPT.2009.5291575)
  • Document utilisé pour la rédaction de l’article(en) Mathieu Xhonneux et Olivier Bonaventure, « Flexible failure detection and fast reroute using eBPF and SRv6 », 2018 14th International Conference on Network and Service Management (CNSM),‎ (ISBN 978-3-9031-7614-0)
  • Document utilisé pour la rédaction de l’article(en) Kurt J. Lidl, Deborah G. Lidl et Paul R. Borman, « Flexible packet filtering: providing a rich toolbox », Proceedings of the BSDCon 2002 Conference,‎
  • Document utilisé pour la rédaction de l’article(en) Taekho Nam et JongWon Kim, « Open-source IO visor eBPF-based packet tracing on multiple network interfaces of Linux boxes », 2017 International Conference on Information and Communication Technology Convergence (ICTC),‎ (ISBN 978-1-5090-4032-2, DOI 10.1109/ICTC.2017.8190996)
  • Document utilisé pour la rédaction de l’article(en) Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska, Jorge A. Navas, Noam Rinetzky, Leonid Ryzhyk et Mooly Sagiv, « Simple and Precise Static Analysis of Untrusted Linux Kernel Extensions », PLDI 2019: Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation,‎ , p. 1069–1084 (DOI 10.1145/3314221.3314590)
  • Document utilisé pour la rédaction de l’article (en) Simon Jouet, Richard Cziva et Dimitrios P. Pezaros, « Arbitrary packet matching in OpenFlow », 2015 IEEE 16th International Conference on High Performance Switching and Routing (HPSR),‎ (ISBN 978-1-4799-9871-5, DOI 10.1109/HPSR.2015.7483106)
  • Document utilisé pour la rédaction de l’article(en) Nguyen Van Tu, Kyungchan Ko et James Won-Ki Hong, « Architecture for building hybrid kernel-user space virtual network functions », 2017 13th International Conference on Network and Service Management (CNSM),‎ (ISBN 978-3-901882-98-2, DOI 10.23919/CNSM.2017.8256051)
  • Document utilisé pour la rédaction de l’article (en) Sabur Baidya, Yan Chen et Marco Levorato, « eBPF-based content and computation-aware communication for real-time edge computing », IEEE INFOCOM 2018 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS),‎ (ISBN 978-1-5386-5979-3, DOI 10.1109/INFCOMW.2018.8407006)
  • Document utilisé pour la rédaction de l’article (en) Andrew Begel, Steven McCanne et Susan L. Graham, « BPF+: exploiting global data-flow optimization in a generalized packet filter architecture », ACM SIGCOMM Computer Communication Review, vol. 29, no 4,‎ , p. 123-134 (DOI 10.1145/316194.316214)
  • Document utilisé pour la rédaction de l’article (en) Simon Jouet et Dimitrios P. Pezaros, « BPFabric: Data Plane Programmability for Software Defined Networks », 2017 ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS),‎ (ISBN 978-1-5090-6386-4, DOI 10.1109/ANCS.2017.14)
  • Document utilisé pour la rédaction de l’article (en) Jibum Hong, Seyeon Jeong, Jae-Hyoung Yoo et James Won-Ki Hong, « Design and Implementation of eBPF-based Virtual TAP for Inter-VM Traffic Monitoring », 2018 14th International Conference on Network and Service Management (CNSM),‎ (ISBN 978-3-9031-7614-0)
  • Document utilisé pour la rédaction de l’article (en) Using eBPF as an Abstraction for Switching, 2018
    Écrit avec Nicolaas Viljoen.
  • Document utilisé pour la rédaction de l’article (en) TCP-BPF: Programmatically tuning TCP behavior through BPF, 2018
    Écrit avec Lawrence Brakmo.
  • Document utilisé pour la rédaction de l’article(en) eBPF / XDP based firewall and packet filtering, 2018
    Écrit avec Anant Deepak, Shankaran Gnanashanmugam, Richard Huang, Puneet Mehra.
  • Document utilisé pour la rédaction de l’article(en) FFPF: Fairly Fast Packet Filters, 2004
    Écrit avec Herbert Bos , Willem de Bruijn , Mihai Cristea, Trung Nguyen, Georgios Portokalidis.
  • (en) Combining kTLS and BPF for Introspection and Policy Enforcement, 2018
    Écrit avec Daniel Borkmann, John Fastabend.
  • Document utilisé pour la rédaction de l’article(en) Bringing the Power of eBPF to Open vSwitch, 2018
    Écrit avec William Tu Joe Stringer Yifeng Sun Yi-Hung Wei.
  • (en) Xenofontas Dimitropoulos, Michail Vlachos et Luca Deri, « pcapIndex: an index for network packet traces with legacy compatibility », ACM SIGCOMM Computer Communication Review, vol. 42,‎ , p. 47-53 (DOI 10.1145/2096149.2096156)
  • (en) Jibum Hong, Seyeon Jeong, Jae-Hyoun Yoo et James Won-Ki Hong, « Design and Implementation of eBPF-based Virtual TAP for Inter-VM Traffic Monitoring », 2018 14th International Conference on Network and Service Management (CNSM),‎ (ISBN 978-1-5386-9193-9, ISSN 2165-9605)

Site Web

[modifier | modifier le code]

Voir aussi

[modifier | modifier le code]
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Berkeley_Packet_Filter&oldid=225098681 ».