eBPF: Como o Linux Ganhou um Kernel Seguro, Rápido e Programável

O Problema com a Abordagem Antiga

Por décadas, se você quisesse mudar como o kernel Linux tratava pacotes, filtrava syscalls ou rastreava gargalos de desempenho, tinha duas opções: submeter um patch para o kernel e esperar anos até que chegasse às distribuições, ou escrever um módulo de kernel. Módulos de kernel são poderosos, mas perigosos. Um bug em um módulo derruba o host. Eles são específicos para cada versão do kernel, então um módulo compilado para a 5.15 quebra na 6.1. Implantá-los em uma frota heterogênea significa manter dezenas de builds. Para uma empresa que opera centenas de milhares de servidores, isso não é um problema de engenharia — é um passivo.

O eBPF resolve isso. Ele permite injetar lógica personalizada no kernel em execução — para rede, segurança ou observabilidade — de forma segura, portável e sem reinicializar nada.

O Que é o eBPF de Fato

O BPF (Berkeley Packet Filter) foi criado em 1992 para tornar o tcpdump rápido. Em vez de copiar cada pacote para o espaço do usuário para filtragem, o BPF executava uma pequena máquina virtual dentro do kernel para filtrar pacotes no local. Era limitado por design.

Em 2014, Alexei Starovoitov e Daniel Borkmann introduziram o extended BPF no Linux 3.18. O conjunto de instruções foi redesenhado para arquiteturas de 64 bits, o número de registradores foi expandido e — de forma crucial — o conjunto de pontos de ancoragem explodiu muito além da filtragem de pacotes. Hoje é possível anexar programas eBPF a caminhos de entrada e saída de rede, tracepoints, kprobes (sondas dinâmicas de funções do kernel), uprobes (sondas de funções no espaço do usuário) e pontos de entrada/saída de syscalls. O kernel se tornou programável.

O modelo de segurança é o que torna tudo isso viável em produção. Você escreve um programa eBPF em C restrito, ou usando bibliotecas em Go ou Rust que emitem bytecode eBPF. Antes de o programa ser executado, o verificador do kernel analisa estaticamente todos os caminhos de execução possíveis: sem loops ilimitados, sem acesso a memória fora dos limites, sem aritmética de ponteiros insegura. Programas que falham na verificação são rejeitados imediatamente. Os que passam são compilados com JIT para código de máquina nativo — portanto, não há overhead de interpretador em tempo de execução. O resultado é código executando dentro do kernel em velocidade quase nativa, com garantias de segurança impostas automaticamente pelo próprio kernel.

XDP e a Revolução em Redes

A capacidade eBPF mais impactante para equipes de infraestrutura é o XDP — eXpress Data Path. Os hooks XDP são executados antes que a pilha de rede do kernel processe um pacote. Antes da alocação do sk_buff. Antes da consulta de roteamento. Antes de qualquer coisa. Um programa XDP pode descartar, redirecionar ou modificar um pacote na camada do driver de NIC a mais de 100 milhões de pacotes por segundo em hardware comum.

Para defesa contra DDoS, isso muda tudo. Um ataque volumétrico que saturaria o caminho de rede normal do kernel — enchendo filas de sockets, esgotando CPU no tratamento de interrupções — é descartado na camada do driver antes que qualquer um desses overheads ocorra. A Cloudflare usa programas eBPF baseados em XDP para absorver ataques DDoS em escala de terabit. O pacote jamais chega à pilha. O host permanece operante.

A Meta foi além. Eles substituíram toda a sua infraestrutura de balanceamento de carga — anteriormente construída sobre IPVS — pelo Katran, um balanceador de carga open-source baseado em eBPF/XDP. O Katran roda em cada servidor nos data centers da Meta, lidando com o tráfego em escala do Facebook sem appliances dedicados de balanceamento de carga. A flexibilidade do eBPF significa que eles podem atualizar a lógica de balanceamento carregando um novo programa, sem reinicializar ou reimplantar hardware.

Redes no Kubernetes via Cilium

O problema de rede no Kubernetes é complexo. Cada pod precisa de um IP. Os pods precisam se comunicar entre nós. Políticas de rede precisam ser aplicadas. O balanceamento de carga de serviços precisa acontecer. A resposta tradicional era o iptables — um motor de regras que não escala. Com alguns milhares de regras, a consulta ao iptables se torna O(n) e o consumo de CPU cresce visivelmente. Com dezenas de milhares de pods, ele colapsa.

O Cilium substitui completamente o iptables por eBPF. Roteamento pod a pod, balanceamento de carga de serviços e aplicação de políticas de rede acontecem todos em programas eBPF anexados às interfaces de rede. As consultas são O(1) via mapas hash do eBPF. A aplicação de políticas ocorre no caminho rápido do kernel. O Cilium também compreende HTTP, gRPC e Kafka na Camada 7 — porque programas eBPF podem inspecionar o conteúdo dos pacotes, não apenas os cabeçalhos.

A adoção é reveladora. AWS EKS, Google GKE e Azure AKS oferecem o Cilium como CNI padrão ou recomendado. Clusters Kubernetes rodando centenas de nós com milhares de pods utilizam eBPF para cada decisão de pacote, e o gargalo do iptables ficou para trás.

Observabilidade Sem Instrumentação

As ferramentas tradicionais de APM exigem mudanças no código: adicionar uma biblioteca, envolver funções, reimplantar. A observabilidade com eBPF não requer nada disso. Você anexa um kprobe ou uprobe a qualquer função do kernel ou do espaço do usuário e coleta dados — latência, argumentos, valores de retorno, stack traces — sem modificar a aplicação.

A Netflix usa o bpftrace em produção exatamente para isso. O bpftrace é uma linguagem de script de alto nível para eBPF, comparável ao que o DTrace era no Solaris. Uma única linha pode rastrear todo I/O de disco acima de 1ms em um host de produção, ou gerar histogramas de latências de conexões TCP, ou encontrar quais processos estão causando mais trocas de contexto — tudo com overhead medido em percentuais de um dígito, não os 10–30% típicos do profiling tradicional.

O Pixie vai além para o Kubernetes, instrumentando automaticamente cada serviço de um cluster usando eBPF para capturar dados de requisição/resposta, distribuições de latência e taxas de erro sem qualquer configuração por serviço. Sem sidecars. Sem integração de SDK. A observabilidade está incorporada na camada do kernel.

Aplicação de Segurança no Nível do Kernel

O seccomp-BPF já filtra syscalls em containers Linux há anos — é o que Docker, Chrome e Firefox usam para restringir quais chamadas de sistema um processo em sandbox pode fazer. Esse é o lado mais limitado da segurança com eBPF.

O lado mais amplo é a aplicação de segurança em tempo de execução. O Falco usa eBPF para monitorar cada syscall em um cluster Kubernetes e alertar sobre comportamentos suspeitos — um container abrindo um shell, um processo escrevendo em /etc, uma conexão de rede para um IP inesperado. O Tetragon, do projeto Cilium, vai ainda mais longe: ele não apenas detecta violações de política em tempo real, mas pode aplicá-las encerrando o processo infrator antes que a syscall seja concluída. A lógica de política roda no kernel via eBPF. Não há janela de corrida entre detecção e resposta.

Portabilidade: CO-RE e BTF

Uma reclamação persistente sobre o eBPF era o acoplamento à versão do kernel. Um programa eBPF compilado com os headers do kernel 5.15 poderia não funcionar na 6.1 se os layouts das structs mudassem. O CO-RE — Compile Once, Run Everywhere — resolve isso. Com o BTF (BPF Type Format), o kernel expõe suas informações de tipo interno em tempo de execução. O carregador eBPF usa o BTF para realocar acessos a campos no momento do carregamento, adaptando o programa compilado a qualquer kernel que esteja realmente em execução. Um único binário eBPF agora pode rodar em toda uma frota com kernels mistos sem recompilação.

O Que Vem a Seguir

A Microsoft está ativamente portando o eBPF para Windows por meio do projeto ebpf-for-windows. Fabricantes de SmartNIC estão adicionando offload de hardware para programas eBPF, de modo que a filtragem XDP possa rodar na própria NIC, liberando completamente as CPUs do host. Runtimes eBPF no espaço do usuário estão amadurecendo, permitindo extensibilidade sandboxada no estilo eBPF fora do kernel.

O padrão subjacente é consistente: um mecanismo de extensão programável com fortes garantias de segurança supera o código de kernel estático para qualquer coisa que precise evoluir na velocidade da produção. O eBPF não apenas melhorou as redes e a observabilidade do Linux — ele mudou o modelo de como o comportamento do kernel é estendido. As equipes de infraestrutura que entenderam isso cedo estão operando com mais velocidade, mais segurança e em maior escala do que aquelas que ainda escrevem regras de iptables e módulos de kernel.