Engenheiros usam eBPF para inspecionar o comportamento do kernel Linux sem módulos de kernel

Dan Fineran, principal community advocate da Isovalent na Cisco, disse ao InfoQ que os desenvolvedores agora usam eBPF muito além da filtragem de pacotes, com equipes aplicando-o à observabilidade do Linux, à rede do Kubernetes, à aplicação de syscall e aos primeiros experimentos no Windows.

Os desenvolvedores de kernel criaram o eBPF a partir do modelo mais antigo Berkeley Packet Filter. O BPF original oferecia aos administradores uma forma de filtrar pacotes. O eBPF manteve a ideia de pequenos programas vinculados a ganchos do kernel e então expandiu o modelo para uma camada de extensão mais ampla.

Fineran disse que o apelo começa com o caminho de contribuição do Linux. Uma equipe que quer novo comportamento no kernel pode escrever um patch, buscar revisões dos mantenedores do subsistema, esperar pela inclusão no kernel e depois esperar novamente até que distribuições como Ubuntu ou Red Hat entreguem esse kernel. Esse caminho protege os usuários do Linux, mas desacelera equipes que precisam de observabilidade ou aplicação em produção agora.

As equipes também podem escrever módulos do kernel, mas essa rota traz acoplamento de versões e risco de falhas. Um autor de módulo frequentemente compila contra uma versão específica do kernel. Código ruim de módulo pode bloquear a execução ou derrubar um host. O eBPF oferece aos desenvolvedores um alvo menor com proteções mais fortes.

A proteção que Fineran destacou é o verificador. Os desenvolvedores compilam o código eBPF em bytecode e então pedem ao kernel para carregá-lo. O verificador checa acesso à memória, limites de laço e o comportamento do programa antes de o kernel aceitar o programa. Se o verificador encontra acesso inseguro ou um caminho de execução que pode rodar sem limites, ele recusa o programa.

Esse modelo dá aos engenheiros de plataforma um caminho de implantação dinâmica para comportamentos em nível de kernel. É possível anexar código a ganchos suportados em um sistema em execução e removê-lo sem reconstruir o kernel. Ainda é necessário conhecimento de baixo nível, muitas vezes em C e, cada vez mais, com ferramentas em Rust, mas isso evita o perfil de risco operacional de um módulo completo de kernel.

Fineran também contestou a ideia de que os desenvolvedores precisam aprender eBPF antes de poderem usar ferramentas baseadas em eBPF. O Cilium, o projeto de rede para Kubernetes da Isovalent, esconde grande parte dessa maquinaria por trás de abstrações de política e serviço. Os operadores definem quais workloads podem se comunicar entre si. Os engenheiros do Cilium usam eBPF internamente para direcionar pacotes e aplicar políticas.

O mesmo padrão se aplica ao Tetragon, que os engenheiros da Isovalent construíram para segurança em runtime e observabilidade. Equipes de segurança podem usar políticas do Tetragon sem escrever programas eBPF brutos. O Tetragon se conecta a syscalls e outros ganchos do kernel, registra atividades e pode bloquear ações específicas antes de o kernel concluí-las.

Esse modelo pré-gatilho muda as operações de segurança. Um agente tradicional pode registrar a exclusão de um arquivo ou uma escalada de privilégio depois que o kernel conclui a ação. Com eBPF, uma equipe de segurança pode colocar lógica antes de uma syscall e interromper a operação. Fineran deu exemplos como bloquear exclusões em um diretório de projeto protegido, limitar o acesso a arquivos de banco de dados ao daemon do banco de dados ou impedir escalada de privilégio fora de caminhos aprovados.

Engenheiros também podem usar políticas do Tetragon para mitigar padrões conhecidos de vulnerabilidade. Se uma equipe entende que uma função vulnerável trata incorretamente entrada acima de um certo tamanho, ela pode anexar uma política antes do caminho vulnerável e rejeitar entradas que correspondam ao padrão de exploração. Isso não substitui a aplicação de patches, mas dá às equipes de operações uma forma de reduzir a exposição enquanto os responsáveis pela aplicação preparam correções permanentes.

Fineran relacionou o mesmo mecanismo à observabilidade. Os desenvolvedores podem anexar programas a probes do kernel, return probes, tracepoints, syscalls e probes de espaço de usuário. Isso dá às equipes visibilidade sobre acesso a arquivos, chamadas de rede, chamadas de biblioteca, caminhos de armazenamento e comportamento de drivers sem adicionar bibliotecas de instrumentação a cada aplicação.

A utilização de GPU ofereceu um exemplo. Fineran descreveu equipes que anexam programas eBPF próximos aos caminhos do driver NVIDIA CUDA para ler atividades de baixo nível e correlacioná-las com a demanda da workload. As equipes de plataforma podem usar esse sinal para manter aceleradores caros ocupados e reduzir capacidade desperdiçada.

Os desenvolvedores ainda precisam entender os limites. O verificador restringe o tamanho do programa, o comportamento de laços e o acesso à memória. As mensagens de erro podem ser desafiadoras para usuários novos, especialmente quando o verificador retorna diagnósticos densos. Fineran disse que a comunidade melhorou ferramentas e documentação, incluindo o Learning eBPF de Liz Rice e os recursos da comunidade eBPF.

A Microsoft também abriu um caminho para eBPF no Windows por meio do projeto eBPF for Windows. Usuários do Linux recebem suporte a eBPF no kernel, enquanto usuários do Windows ainda precisam de drivers extras. Fineran disse que essa direção multiplataforma pode ajudar organizações a unificar observabilidade e políticas em sistemas operacionais mistos.

A conversa também abordou micro VMs e isolamento no Kubernetes. Fineran disse que as equipes podem combinar isolamento de kernel com controles de runtime baseados em eBPF. Micro VMs reduzem o risco de kernel compartilhado, enquanto o Tetragon ainda pode inspecionar e aplicar políticas dentro de ambientes convidados suportados. A Edera, disse ele, adicionou suporte a eBPF dentro do kernel da sua micro VM.

Operações orientadas por IA surgiram como um caminho futuro. Fineran disse que a Cisco e a comunidade experimentaram políticas Tetragon geradas por modelo, embora os modelos atuais possam produzir campos de política que parecem plausíveis e falham na validação. Ele descreveu um fluxo de trabalho provável em que uma ferramenta de vulnerabilidade identifica o formato de um exploit, um modelo redige uma política e um sistema de validação humano ou automatizado testa a política antes da implantação.

Esse fluxo de trabalho exige revisão. Fineran alertou que usuários de código aberto devem inspecionar a força da manutenção, a cadência de atualizações, a profundidade do suporte e a procedência do código antes de adotar projetos eBPF. Código gerado por IA pode aumentar o volume de contribuições, mas os responsáveis pelo projeto ainda precisam de entendimento suficiente para corrigir bugs, dar suporte aos usuários e manter o projeto após mudanças de modelo ou de ferramentas.

Para a maioria dos desenvolvedores, o eBPF continuará sendo um detalhe de implementação dentro de ferramentas como Cilium e Tetragon. Para equipes de plataforma, segurança e observabilidade, ele oferece uma forma direta de inspecionar e moldar o comportamento do sistema na fronteira do kernel, sem enviar módulos de kernel ou esperar mudanças no kernel upstream.