Surveillance du trafic eBPF

L'outil de trafic réseau eBPF utilise une combinaison d'implémentation du noyau et de l'espace utilisateur pour surveiller l'utilisation du réseau sur le périphérique depuis le dernier démarrage du périphérique. Il fournit des fonctionnalités supplémentaires telles que le marquage des sockets, la séparation du trafic de premier plan/arrière-plan et un pare-feu par UID pour bloquer l'accès des applications au réseau en fonction de l'état du téléphone. Les statistiques collectées à partir de l'outil sont stockées dans une structure de données du noyau appelée eBPF maps et le résultat est utilisé par des services comme NetworkStatsService pour fournir des statistiques de trafic persistantes depuis le dernier démarrage.

Exemples et source

Les changements dans l'espace utilisateur concernent principalement les projets system/netd et framework/base . Le développement est effectué en AOSP, le code AOSP sera donc toujours à jour. La source se trouve principalement dans system/netd/server/TrafficController* , system/netd/bpfloader et system/netd/libbpf/ . Certains changements de framework nécessaires concernent également framework/base/ et system/core .

Mise en œuvre

À partir d'Android 9, les appareils Android fonctionnant sur le noyau 4.9 ou supérieur et initialement livrés avec la version P DOIVENT utiliser la comptabilité de surveillance du trafic réseau basée sur eBPF au lieu de xt_qtaguid . La nouvelle infrastructure est plus flexible et plus maintenable et ne nécessite aucun code noyau hors arborescence.

Les principales différences de conception entre la surveillance du trafic héritée et eBPF sont illustrées dans la figure 1.

Différences de conception de surveillance du trafic héritée et eBPF

Figure 1. Différences de conception de surveillance du trafic héritée (à gauche) et eBPF (à droite)

La nouvelle conception trafficController est basée sur le filtre cgroup eBPF ainsi que sur le module xt_bpf netfilter à l'intérieur du noyau. Ces filtres eBPF sont appliqués sur les paquets tx/rx lorsqu'ils traversent le filtre. Le filtre cgroup eBPF est situé au niveau de la couche transport et est chargé de compter le trafic par rapport au bon UID en fonction de l'UID du socket ainsi que des paramètres de l'espace utilisateur. Le netfilter xt_bpf est connecté aux chaînes bw_raw_PREROUTING et bw_mangle_POSTROUTING et est responsable du comptage du trafic par rapport à l'interface correcte.

Au moment du démarrage, le processus de l'espace utilisateur trafficController crée les cartes eBPF utilisées pour la collecte de données et épingle toutes les cartes en tant que fichier virtuel sur sys/fs/bpf . Ensuite, le processus privilégié bpfloader charge le programme eBPF précompilé dans le noyau et l'attache au bon cgroup . Il existe un seul cgroup contrôle racine pour tout le trafic, donc tous les processus doivent être inclus dans ce cgroup par défaut.

Au moment de l'exécution, trafficController peut baliser/démarquer un socket en écrivant dans traffic_cookie_tag_map et traffic_uid_counterSet_map . Le NetworkStatsService peut lire les données de statistiques de trafic à partir de traffic_tag_stats_map , traffic_uid_stats_map et traffic_iface_stats_map . Outre la fonction de collecte de statistiques de trafic, le trafficController et le filtre cgroup eBPF sont également chargés de bloquer le trafic de certains UID en fonction des paramètres du téléphone. La fonctionnalité de blocage du trafic réseau basée sur l'UID remplace le module xt_owner à l'intérieur du noyau et le mode détail peut être configuré en écrivant dans traffic_powersave_uid_map , traffic_standby_uid_map et traffic_dozable_uid_map .

La nouvelle implémentation suit l'ancienne implémentation du module xt_qtaguid , de sorte que TrafficController et NetworkStatsService fonctionneront avec l'ancienne ou la nouvelle implémentation. Si l'application utilise des API publiques, il ne devrait y avoir aucune différence selon que les outils xt_qtaguid ou eBPF sont utilisés en arrière-plan.

Si le noyau de l'appareil est basé sur le noyau commun Android 4.9 (SHA 39c856663dcc81739e52b02b77d6af259eb838f6 ou supérieur), aucune modification des HAL, des pilotes ou du code du noyau n'est requise pour implémenter le nouvel outil eBPF.

Exigences

  1. La configuration du noyau DOIT avoir les configurations suivantes activées :

    1. CONFIG_CGROUP_BPF=y
    2. CONFIG_BPF=y
    3. CONFIG_BPF_SYSCALL=y
    4. CONFIG_NETFILTER_XT_MATCH_BPF=y
    5. CONFIG_INET_UDP_DIAG=y

    Le test de configuration du noyau VTS est utile pour vérifier que la configuration correcte est activée.

Processus de dépréciation de xt_qtaguid hérité

Le nouvel outil eBPF remplace le module xt_qtaguid et le module xt_owner sur lequel il est basé. Nous allons commencer à supprimer le module xt_qtaguid du noyau Android et désactiver ses configurations inutiles.

Dans la version Android 9, le module xt_qtaguid est activé sur tous les appareils, mais toutes les API publiques qui lisent directement le fichier proc du module xt_qtaguid sont déplacées vers le service NetworkManagement . En fonction de la version du noyau de l'appareil et du premier niveau d'API, le service NetworkManagement sait si les outils eBPF sont activés et choisit le bon module à obtenir pour chaque statistique d'utilisation du réseau de l'application. Les applications avec le niveau de SDK 28 et supérieur ne peuvent pas accéder aux fichiers proc xt_qtaguid par sepolicy.

Dans la prochaine version d'Android après la version 9, l'accès des applications à ces fichiers proc xt_qtaguid sera complètement bloqué. Nous commencerons à supprimer le module xt_qtaguid des nouveaux noyaux communs Android. Une fois supprimé, nous mettrons à jour la configuration de base Android pour cette version du noyau afin de désactiver explicitement le module xt_qtaguid . Le module xt_qtaguid sera complètement obsolète lorsque la version minimale requise du noyau pour une version Android est 4.9 ou supérieure.

Dans la version Android 9, seuls les appareils lancés avec la version Android 9 doivent disposer de la nouvelle fonctionnalité eBPF. Pour les appareils livrés avec un noyau prenant en charge les outils eBPF, nous vous recommandons de le mettre à jour avec la nouvelle fonctionnalité eBPF lors de la mise à niveau vers la version Android 9. Il n'existe aucun test CTS pour appliquer cette mise à jour.

Validation

Vous devez régulièrement utiliser les correctifs des noyaux communs Android et du principal Android AOSP. Assurez-vous que votre implémentation réussit les tests VTS et CTS applicables, netd_unit_test et libbpf_test .

Essai

Il existe des net_tests du noyau pour garantir que les fonctionnalités requises sont activées et que les correctifs du noyau requis sont rétroportés. Les tests sont intégrés dans le cadre des tests VTS de la version Android 9. Il existe des tests unitaires dans system/netd/ ( netd_unit_test et libbpf_test ). Il existe quelques tests dans netd_integration_test pour valider le comportement global du nouvel outil.

Vérificateur CTS et CTS

Étant donné que les deux modules de surveillance du trafic sont pris en charge dans la version Android 9, il n'existe aucun test CTS pour forcer la mise en œuvre du nouveau module sur tous les appareils. Mais pour les appareils avec une version de noyau supérieure à 4.9 initialement livrée avec la version Android 9 (c'est-à-dire le premier niveau d'API >= 28), il existe des tests CTS sur GSI pour valider que le nouveau module est correctement configuré. Les anciens tests CTS tels que TrafficStatsTest , NetworkUsageStatsTest et CtsNativeNetTestCases peuvent être utilisés pour vérifier que le comportement est cohérent avec l'ancien module UID.

Tests manuels

Il existe des tests unitaires dans system/netd/ ( netd_unit_test , netd_integration_test et libbpf_test ). Il existe un support dumpsys pour vérifier manuellement l'état. La commande dumpsys netd affiche l'état de base du module trafficController et si eBPF est correctement activé. Si eBPF est activé, la commande dumpsys netd trafficcontroller affiche le contenu détaillé de chaque carte eBPF, y compris les informations sur les sockets balisées, les statistiques par balise, l'UID et l'iface, ainsi que la correspondance de l'UID du propriétaire.

Lieux de test

Les tests CTS se trouvent à l'adresse :

Les tests VTS se trouvent sur https://android.googlesource.com/kernel/tests/+/main/net/test/bpf_test.py .

Les tests unitaires se trouvent à l'adresse :