Nous allons tout d’abord rajouter dans le fichier samples/bpf/Makefile les instructions pour compiler notre futur programme. Vous verrez dans ce fichier de multiples déclarations commençant par hostprogs-y, rajouter la ligne hostprogs-y += xdp_ip_filter.

De la même façon, rajoutez la ligne xdp_ip_filter-objs := bpf_load.o xdp_ip_filter_user.o à l’endroit où se trouve les déclarations commençant par xdp_, puis always += xdp_ip_filter_kern.o un peu plus loin.

Le Makefile est maintenant prêt.

Nous allons travailler dans deux fichiers samples/bpf/xdp_ip_filter_kern.c et samples/bpf/xdp_ip_filter_user.c. Le fichier kern contiendra le code qui sera compilé en bytecode BPF, le fichier user sera notre point d’entrée pour démarrer ce dernier. Je me référerais souvent à ces fichiers par les noms abrégés user ou kern.

Le code de ces fichiers est disponible à ces deux emplacements:

Il faut savoir que je n’ai pas fait de C depuis très longtemps (et j’ai jamais pratiqué le C à haut niveau), donc mon code est assez moche (mais ce n’est pas très grave pour cet exemple ¯_(ツ)_/¯).
Je vous conseille également de lire cet article en ayant ouvert dans votre éditeur favoris les deux fichiers.

On a maintenant une partie plus intéressante:

On définit ici deux maps. Ces maps sont donc des associations clé/valeurs, et c’est ces maps qui sont utilisées pour intéragir avec l’extérieur (notre fichier user que je présenterais tout à l’heure). Le programme user pourra lire et écrire dans ces maps, même chose pour le programme kern. Vous pouvez donc voir les maps comme de la mémoire partagée entre les deux programmes, et c’est d’ailleurs à ma connaissance la seule façon de faire communiquer ces programmes entre eux.

La première map ip_map est une map de type BPF_MAP_TYPE_HASH (voyez ça comme une map classique), dont les clés et valeurs sont des u32 (en effet, une addresse IP v4 peut être représentée sous forme d’un simple integer). Cette map ne peut contenir qu’une entrée (cf max_entries).
Cette map servira au programme user à transmettre au programme kern l’adresse IP à filtrer (et ici, on ne filtre qu’une IP donc la map n’aura qu’une entrée).

La seconde map nommée counter_map est une map de type BPF_MAP_TYPE_PERCPU_ARRAY. Ce type indique que l’on aura en fait une map par core de notre CPU (si vous avez 8 cores, vous aurez 8 maps). Ces map serviront à compter par core combien de paquets ont été filtrés. Le type ARRAY indique également que la clé de notre map sera entre 0 et max_entries -1 (donc dans notre cas nous n’aurons qu’une entrée pour la clé 0). On aura donc pour chaque core une map dont la valeur pour la clé 0 contiendra le nombre de paquets filtrés par ce core.

Récupération de l’IP à filtrer

Ici, nous avons une fonction prenant en paramètre une struct xdp_md. Cette struct contiendra le paquet réseau avec lequel nous allong intéragir.

La première chose à faire est de récupérer dans la map ip_map l’ip addresse que nous voulons filtrer. Pour cela, nous utilisons bpf_map_lookup_elem sur ip_map avec comme clé 0 (rappelez vous, notre map n’a qu’un élément). Comme dit précédemment, l’IP retournée par bpf_map_lookup_elem est sous format u32 en little endian (par exemple 192.168.1.78 ⇒ 0xC0A8014E en hexadécimal ⇒ on lit à l’envers ⇒ 0x4E0180C0 ⇒ 1308721344 en base 10).
Vous pouvez voir également que j’utilise bpf_printk comme un logger.

Récupération de l’IP source du paquet

Maintenant, nous voulons récupérer l’adresse IP source du paquet.

Nous commençons par récupérer la donnée contenue dans ctx grâce à ctx→data, et un pointer sur la fin du paquet via (void *)(long)ctx→data_end. Ensuite, on assigne data à une struct de type ethhdr (représentant une trame Ethernet).

On doit ensuite vérifier que eth + 1 ne dépasse pas data_end en mémoire. Ce check est obligatoire (sans cela, le programme refuse de compiler). Si la taille est supérieuse, on ne fait rien (on laisse passer le paquet en retournant XDP_PASS).

On vérifie ensuite que le paquet est un paquet IP via if(ntohs(eth→h_proto) != ETH_P_IP). Si le paquet n’est pas un paquet IP, il ne nous intéresse pas, donc là aussi on retourne XDP_PASS.

Nous créons maintenant une nouvelle struct de type iphdr à partir de la struct ethernet, nous refaisons également une vérification (obligatoire) sur data_end, puis nous récupérons enfin l’IP source du paquet via iph→saddr.

Filtrer le paquet

On a maintenant l’IP source, nous allons la comparer avec l’IP que nous avons récupérée dans la map en début de programme:

Ici, on compare ip_src avec ip. Si le paquet source doit être filtré, on incrémente dans la map counter_map le compteur de paquet filtré (en utilisant encore la clé 0) via bpf_map_lookup_elem (qui retourne un pointeur dont on peut donc incrémenter la valeur), et on filtre le paquet en retournant XDP_DROP. Sinon, on retourne XDP_PASS.

C’est tout pour le programme kern !

Ce fichier commence comme l’autre par l’inclusion de nombreux fichiers headers, puis de:

On définit ici une variable ifindex qui est l’index de l’interface localhost (je parlerais plus en détail de cela plus loin), puis xdp_flags qui vaut zéro.

La fonction int_exit est une fonction servant à stopper le programme kern en cas de signal, via bpf_set_link_xdp_fd.

La fonction main, récupération de l’IP

Voici maintenant la fonction main qui sera exécutée pour démarrer notre programme BPF:

Ici, on définit quelques variables comme les paramètres attendues à main, le nom du fichier .o (xdp_ip_filter_kern.o) qui devra être lancé, et une valeur par défaut pour l’IP à filtrer (127.0.0.1).

On récupère l’IP à filtrer (qui sera passé via l’option -i au programme), et on la convertit en un u32 (par exemple "192.168.1.78" ⇒ 0xC0A8014E ⇒ on lit à l’envers ⇒ 0x4E0180C0 ⇒ 1308721344 en base 10).

Changements de limits

On voit dans beaucoup de programmes eBPF que les limites du système sont augmentées, j’ai laissé ce comportement:

Chargement du programme eBPF

Ici, on charge le fichier xdp_ip_filter_kern.o (qui contient notre fichier précédent compilé), et on ajoute le handler int_exit sur les signaux SIGINT et SIGTERM.

Ajout de l’IP à filtrer dans la map

Il faut maintenant ajouter l’IP que nous voulons filtrer dans la map nommée ip_map que nous avons utilisée dans le fichier xdp_ip_filter_kern.c:

Ici, on met à jour la map avec la fonction bpf_map_update_elem. map_fd[0] retourne la première map définie dans le fichier kern, qui est bien notre map ip_map (l’ordre de déclaration des maps a donc de l’importance !). La map contiendra donc maintenant pour la clé 0 l’IP à filtrer (et donc le programme kern pourra la récupérer comme vu précédemment).

Ajout du programme XDP sur une interface

Dans la fonction int_exit vue précédemment, nous appelions bpf_set_link_xdp_fd pour stopper le programme XDP, en utilisant notamment la variable ifindex. En fait, un programme XDP est lié à une interface (et dans int_exit, nous le détachions donc de l’interface).

Il faut donc dans notre main l’attacher à l’interface dont nous voulons filtrer les paquets:

Ici, on attachons à l’interface localhost notre programme XDP.

Collecte des statistiques

A partir de ce moment, notre programme XDP est démarré, et commence à filtrer des paquets. Nous voulons savoir combien de paquets ont été filtrés, en récupérant pour chaque core de notre CPU la valeur dans la map counter_map vue précédemment.

Rappelez vous, la map counter_map est par core (type BPF_MAP_TYPE_PERCPU_ARRAY). Nous récupérons notre nombre de core via bpf_num_possible_cpus, puis nous créons deux boucles:

Fin du programme

A la fin du programme, on détache le programme de l’interface localhost.

C’est maintenant terminé, place à la compilation et aux tests !