Résumé

  • RFC 9669 normalise l’encodage des instructions BPF et des groupes de conformité ; il ne définit pas à lui seul l’admission d’un programme par une plateforme.
  • L’authenticité des octets, le verdict du vérificateur, le chargement, l’attachement, l’invocation et l’effet externe doivent rester des faits séparés.

La chaîne de publication possédait un reçu cryptographique impeccable. La signature couvrait le programme soumis et le registre de confiance contenait la bonne clé. L’interface de gouvernance a traduit ce fait par « programme approuvé ».

Le noyau a ensuite refusé le chargement. Sur un chemin de contrôle, un registre devenait une valeur scalaire là où l’appel suivant exigeait un pointeur valide. Les octets étaient authentiques ; le programme n’était pas admissible dans ce contexte.

Ce contraste ne réduit pas l’utilité de la signature. Il empêche seulement un reçu précis d’être promu en autorisation générale.

Ce que le standard met réellement en commun

RFC 9669 fournit une architecture de jeu d’instructions. Une instruction de base occupe 64 bits ; une instruction large en occupe 128. Les champs d’opcode, de registres, de décalage et de valeur immédiate ont une interprétation définie par la classe d’instruction. Un compilateur et un environnement d’exécution peuvent ainsi parler d’une même opération sans partager toute leur implémentation.

Le document n’exige pas la totalité du catalogue. Toute implémentation doit prendre en charge base32, puis peut annoncer d’autres groupes. base64 inclut base32, atomic64 inclut atomic32, et divmul64 inclut divmul32. Soutenir un groupe signifie soutenir toutes les instructions qui lui appartiennent.

Cette règle transforme une affirmation vague — « cette machine fait du BPF » — en capacités nommées. Le registre IANA conserve les relations d’inclusion et d’exclusion, le statut, le contrôleur et la référence. Le registre des instructions associe en outre des combinaisons de champs à une sémantique et à un ou plusieurs groupes.

Un statut Permanent n’est toutefois pas une mesure de déploiement. Il stabilise l’attribution et sa gouvernance. Il ne dit pas si le noyau installé, le type de programme, la politique locale ou une cible d’offload exécutera l’instruction. La découverte de capacités reste un acte local à dater et à rattacher à une version.

La grammaire ne valide pas la phrase entière

Des opcodes connus peuvent composer un programme invalide. Les sauts de RFC 9669 comptent en unités de 64 bits. Atterrir sur la deuxième moitié d’une instruction large de 128 bits entraîne un comportement indéfini. Chaque morceau peut sembler familier alors que l’enchaînement ne possède aucune signification exécutable sûre.

Les références de map et les appels exposent la même limite. L’ISA décrit des opérations abstraites, mais la plateforme décide quelles fonctions existent, quel contexte accompagne un type de programme et quels objets peuvent être liés. Une fonction disponible pour le filtrage d’un socket n’est pas automatiquement disponible pour un autre point d’attache.

RFC 9669 rappelle le rôle des vérificateurs : terminaison, sûreté des accès mémoire, respect des contrats d’API de la plateforme et absence de comportement indéfini. Puis il place leurs détails hors de son périmètre. L’architecture définit le langage commun ; l’environnement d’exécution décide si un programme donné peut parler dans un contexte privilégié.

La documentation Linux montre ce travail en deux grandes étapes. Le vérificateur contrôle d’abord le graphe de flux, puis simule les chemins possibles en suivant l’état des registres et de la pile. Des callbacks propres au type de programme déterminent les champs de contexte accessibles et les prototypes d’appel permis. Une adresse numériquement plausible peut rester interdite parce que son type, son alignement ou sa borne ne convient pas.

La FAQ de conception Linux formule une règle opérationnelle sans détour : pour savoir si ce vérificateur acceptera réellement le programme, il faut essayer de le charger. Les limites internes et les connaissances du vérificateur évoluent. Un inventaire d’instructions ne rend pas ce test superflu.

« Signé » ne veut pas dire « chargé »

La documentation actuelle de signature BPF sous Linux précise que la signature est orthogonale aux permissions et au vérificateur. Un verdict BPF_SIG_VERIFIED reçu à un point d’admission précoce signifie que la signature a été validée selon sa couverture. Il ne signifie pas encore que le programme a terminé la vérification ou qu’un objet a été chargé. Des contrôles de mémoire, de flux ou de liaison peuvent toujours échouer.

Ce mécanisme Linux ne fait pas partie des obligations de RFC 9669 et il ne faut pas supposer qu’il existe partout. Il sert ici de preuve de méthode : plus un reçu est fort, plus son objet doit être formulé exactement. La signature répond à « qui a produit ces octets et ont-ils changé ? ». Le vérificateur répond à « ce programme respecte-t-il les règles de cette cible ? ».

Après cela viennent encore d’autres questions. Le chargement a-t-il créé le bon objet ? Le lien souhaité pointe-t-il vers cette génération ? Le hook a-t-il été invoqué ? Le programme a-t-il pris la décision attendue ? Une observation extérieure confirme-t-elle l’effet sur le paquet, l’application ou l’équipement ?

Une chaîne de reçus plutôt qu’un feu vert global

Une mise en production vérifiable conserve le hash de la source et de l’objet, les options du compilateur, les groupes de conformité découverts, la version et l’architecture de la cible, le type de programme, les relocations et objets résolus, le verdict et le hash du journal du vérificateur, l’identifiant du programme chargé, l’identité du lien et du hook, la génération des maps, les compteurs d’invocation et une mesure indépendante du résultat.

Les échecs ont besoin du même soin. Groupe absent, relocation impossible, rejet du vérificateur, échec de chargement, attachement refusé, compteur nul et résultat contradictoire ne racontent pas le même incident. Les fusionner sous « BPF indisponible » empêche de corriger la bonne couche.

Une génération explicite protège aussi le rollback. Charger un nouveau programme ne retire pas nécessairement un ancien lien. Réutiliser une map peut mélanger les compteurs. Un tableau de bord joint par nom de politique peut alors présenter la nouvelle version alors que le trafic traverse l’ancienne.

RFC 9669 offre un minimum initial précieux : un langage d’instructions et une procédure d’extension. Le respecter exige de ne pas lui attribuer les décisions que le standard laisse justement aux environnements d’exécution.

Sources