No eBPF Summit virtual do mês passado, Thomas Graf, que é CTO e cofundador da Isovalent, falou sobre o futuro do filtro de código aberto transformado em mecanismo de kernel. E esse futuro inclui Microsoft Windows, ele observou.
Desde sua inclusão no kernel há uma década, o eBPF baseado em Linux encontrou ampla adoção, particularmente para ferramentas de observabilidade, segurança e conformidade que se beneficiam de sua velocidade programável em linha para analisar e filtrar pacotes sem a necessidade de módulos complicados ou modificações perigosas no kernel.
A Chegada do eBPF no Windows
Em 2021, os engenheiros da Microsoft embarcaram em um projeto para criar uma versão do eBPF para Windows, ou seja, dar ao kernel do Windows uma interface programável semelhante. Com a prometida compatibilidade entre plataformas Windows e Linux, os fabricantes de ferramentas podem escrever binários que rodam em ambas as plataformas.
Assim como o Linux eBPF, o Windows eBPF executará pequenos programas de bytecode eBPF dentro do próprio kernel. Ao contrário da versão Linux, no entanto, a compilação do Windows usa apenas um interpretador para depurar compilações que não sejam de produção. Para uso em produção, ele dependerá da geração de código nativo, que "envolve carregar drivers do Windows que contêm programas eBPF assinados", escreveu o engenheiro de software principal da Microsoft, Alan Jowett, em uma postagem de blog de 2022.
"Devido aos riscos associados a ter um interpretador no espaço de endereço do kernel, foi decidido habilitá-lo apenas para compilações assinadas que não sejam de produção."
O projeto da Microsoft, capturado no GitHub, conta com 43 colaboradores, com o código escrito principalmente em C, com um pouco de C++. O pacote trará compatibilidade de bytecode com Linux eBPF, disse Graf. Mas os pontos de gancho onde eBPF se conecta ao kernel podem diferir, dadas as diferenças com as chamadas de sistema do Windows.
Arquitetura do eBPF no Windows
A arquitetura do eBPF no Windows envolve a geração de código nativo a partir do bytecode eBPF, que é então carregado como drivers do Windows assinados. Isso evita os riscos de ter um interpretador no espaço de endereço do kernel, que é uma abordagem adotada apenas para compilações não-produção.
Essa abordagem de geração de código nativo visa garantir a segurança e a estabilidade do kernel do Windows, evitando possíveis vulnerabilidades ou instabilidades que poderiam ser introduzidas por um interpretador de bytecode eBPF no kernel.
Impacto na Comunidade de Ferramentas
Todas as ferramentas que foram feitas para o Linux eBPF também serão transferidas para ambientes Windows "nos próximos anos", disse Graf. Ele alertou que isso trará mais desafios para a comunidade.
No futuro, os fabricantes de ferramentas precisarão garantir que seus produtos funcionem em ambos os ambientes, Windows e Linux. Isso significa que eles terão que lidar com as diferenças entre as chamadas de sistema do Windows e do Linux, bem como com possíveis divergências na implementação do eBPF entre as duas plataformas.
Padronização do eBPF
Originalmente, o eBPF (que, os guardiões agora concordam, não representa mais nada) evoluiu como um conjunto de códigos; ele não seguia uma especificação pré-definida que estava implementando, Graf apontou. Como resultado, o código em si "é o padrão" que os fabricantes de ferramentas devem escrever, ele disse.
A Internet Engineering Task Force (IETF) embarcou em um projeto para solidificar um pouco mais as coisas, a fim de garantir o máximo possível de compatibilidade "multiplataforma" entre Windows e Linux, explicou Dave Thaler, consultor técnico do grupo de trabalho que também é um dos principais colaboradores do projeto Microsoft eBPF, em uma apresentação anterior deste ano para o Linux Foundation's Storage Summit.
A primeira tarefa do IETF eBPF Working Group planeja solidificar a Instruction Set Architecture (ISA) para a máquina virtual que executa os programas eBPF. O corpo concluiu o documento que descreve a ISA e está atualmente nos últimos estágios de publicação.
Em seguida, o grupo planeja desenvolver um conjunto de expectativas para o verificador, que garanta a execução segura de programas eBPF não confiáveis. O que um verificado deve fazer para garantir que o código seja seguro? Quais propriedades de segurança um verificador garante? Para esse trabalho, o grupo pode construir a partir do verifier.rst do kernel Linux para eBPF.
O grupo também planeja criar um formato para produzir binários eBPF portáteis por meio de uma especificação ABI (interface binária de aplicativo), talvez baseada em uma das já existentes.
Essa padronização é crucial para garantir a compatibilidade entre as implementações do eBPF no Windows e no Linux, permitindo que as mesmas ferramentas possam ser executadas em ambas as plataformas sem problemas.
Conclusão
O futuro do eBPF inclui sua adoção no Windows, trazendo novos desafios e oportunidades para a comunidade de ferramentas. A abordagem da Microsoft de gerar código nativo a partir do bytecode eBPF visa garantir a segurança e a estabilidade do kernel do Windows.
No entanto, essa expansão do eBPF para o Windows também exigirá uma maior padronização e compatibilidade entre as implementações, para que as mesmas ferramentas possam ser executadas em ambos os ambientes. O trabalho da IETF é crucial nesse sentido, buscando solidificar a arquitetura do eBPF e criar especificações que facilitem a portabilidade entre plataformas.
À medida que o eBPF se expande para o Windows, a comunidade de desenvolvedores de ferramentas terá que se adaptar, garantindo que seus produtos funcionem de maneira consistente em ambos os ecossistemas. Essa transição representa um desafio, mas também uma oportunidade para impulsionar ainda mais a adoção e o impacto do eBPF em todo o setor de tecnologia.
