Microsoft travaille à apporter la prise en charge étendue du filtre de paquets Berkeley (eBPF) à Windows

Icône de temps de lecture 2 minute. lis


Les lecteurs aident à prendre en charge MSpoweruser. Nous pouvons recevoir une commission si vous achetez via nos liens. Icône d'info-bulle

Lisez notre page de divulgation pour savoir comment vous pouvez aider MSPoweruser à soutenir l'équipe éditoriale En savoir plus

Rapports ZDNet que Microsoft travaille à apporter l'outil de sécurité Linux étendu Berkeley Packet Filter (eBPF) à Windows 10.

L'outil peut actuellement être exécuté sur le sous-système Windows pour Linux, mais Microsoft travaille sur un support natif, le problème étant que l'outil exécute du code dans le contexte du noyau, ce qui soulève toutes sortes de complications de sécurité.

Cependant, le travail peut en valoir la peine, car eBPF est largement utilisé dans le filtrage, l'analyse et la gestion des réseaux, ainsi que pour le filtrage des appels système et le suivi du contexte des processus, et constitue la base de plusieurs applications de sécurité telles que Cilium, Falco et Tracee ; Des programmes d'observation Kubernetes comme Hubble et Pixie, et des chaînes d'outils comme Clang.

Le projet ebpf-for-windows vise à prendre plusieurs projets open-source eBPF existants et à ajouter le « colle » pour les faire fonctionner sous Windows.

Comme indiqué dans le diagramme, les chaînes d'outils eBPF existantes (clang, etc.) peuvent être utilisées pour générer du bytecode eBPF à partir du code source dans différents langages. Le bytecode peut être consommé par n'importe quelle application, ou via l'outil de ligne de commande Netsh, qui utilise une bibliothèque partagée qui expose les API Libbpf, bien que cela soit toujours en cours.

Le bytecode eBPF est envoyé à un vérificateur statique (le vérificateur PREVAIL) qui est hébergé dans un processus protégé en mode utilisateur (un environnement de sécurité Windows qui permet à un composant du noyau de faire confiance à un démon en mode utilisateur signé par une clé à laquelle il fait confiance). Si le bytecode réussit toutes les vérifications du vérificateur, il peut être soit chargé dans un interpréteur (depuis uBPF dans le contexte d'exécution en mode noyau), soit compilé JIT (via le compilateur uBPF JIT) et avoir un chargement de code natif dans l'exécution en mode noyau. contexte (mais voir la FAQ en bas sur HVCI).

Les programmes eBPF installés dans le contexte d'exécution en mode noyau peuvent s'attacher à divers crochets (actuellement deux crochets jusqu'à présent : XDP et un crochet de liaison de socket) et appeler diverses API d'assistance exposées par le shim eBPF, qui encapsule en interne les API publiques du noyau Windows, permettant au utilisation d'eBPF sur les versions existantes de Windows. Plus de crochets et d'aides seront ajoutés au fil du temps.

Le résultat final sera un environnement d'hébergement spécifique à Windows pour eBPF qui permettrait aux développeurs Windows d'utiliser des programmes eBPF open source sans avoir à recoder.

Jetez un coup d'œil au projet ebpf-for-windows sur GitHub ici.

En savoir plus sur les sujets : eGMP, microsoft, fenêtres 10

Soyez sympa! Laissez un commentaire

Votre adresse email n'apparaitra pas. Les champs obligatoires sont marqués *