[Tradução] Por que um programa eBPF funciona em um kernel, mas não em outro

Neste artigo, vamos discutir como criar programas eBPF verdadeiramente portáveis.

Em um mundo ideal, todos os sistemas estariam totalmente atualizados, com patches aplicados regularmente e executando a versão mais recente do kernel. Mas sejamos realistas, isso raramente acontece. Alguns ambientes ainda usam versões desatualizadas do Ubuntu ou Fedora, e em outros, o kernel nem sequer é compilado com suporte a BTF (BPF Type Format). E se você oferece suporte a alguma ferramenta de código aberto, a situação se torna ainda mais complexa. Você não tem controle sobre em qual sistema os usuários executarão seu programa.

Tudo isso torna mais difícil garantir que seus programas eBPF funcionem de forma estável em diferentes distribuições e afeta diretamente se sua ferramenta eBPF será usada ou não. Então, como tornar os programas eBPF verdadeiramente portáveis?

Para entender melhor o problema, vamos considerar um exemplo hipotético. Suponha que você compile um programa eBPF no kernel versão 5.3, mas ele não é executado na versão 5.4. Por quê? Porque cada versão do kernel vem com seus próprios arquivos de cabeçalho do kernel, que definem as estruturas de dados e o layout da memória. Mesmo pequenas alterações nessas definições podem quebrar os programas eBPF.

Tomemos, por exemplo, as estruturas. Digamos que temos uma estrutura representando o cabeçalho TCP no kernel 5.3:

c
struct tcp_header {
 __be16 source_port;
 __be16 dest_port;
 __be32 seq_number;
 __be32 ack_number;
 // ...
};

Na próxima versão do kernel, 5.4, os desenvolvedores do kernel podem decidir mover esses campos para uma nova estrutura, renomear o campo seq para sequence ou simplesmente mover esses campos para cima ou para baixo, alterando seu deslocamento:

c
struct tcp_header {
 struct tcp_ports ports;
 __be32 seq_number;
 __be32 ack_number;
 // ...
};

struct tcp_ports {
 __be16 source_port;
 __be16 dest_port;
};

Consegue ver o problema? Seu código pode depender de campos ou deslocamentos específicos, e eles podem mudar de versão para versão do kernel. Como o próprio programa eBPF não pode influenciar tais mudanças, surge uma necessidade natural de uma solução que garanta a portabilidade dos programas eBPF.

Se você pesquisar informações na internet, encontrará muitos materiais que recomendam o uso de BPF CO-RE (Compile Once – Run Everywhere, "compile uma vez – execute em qualquer lugar") para resolver este problema. Em outras palavras, em vez de escrever programas assim:

c
bpf_probe_read(dest, size, src);

Você deve substituir a família de funções auxiliares (helpers) BPF_PROBE_READ() pela família BPF_CORE_READ(), que permite acessar os campos das estruturas de forma que esse acesso seja automaticamente ajustado para diferentes versões do kernel:

c
bpf_core_read(dest, size, src);

Em resumo, a família de helpers BPF_CORE_READ() permite realizar leituras portáveis de estruturas do kernel. Isso significa que, se um determinado campo de uma estrutura (por exemplo, filename no exemplo) estiver em um deslocamento diferente em outro sistema operacional ou versão do kernel, essas funções ainda serão capazes de encontrá-lo e lê-lo corretamente.

Por baixo dos panos, isso funciona graças às informações de realocação BPF CO-RE e BTF (BPF Type Format).

Espere um pouco, o quê? Informações de realocação CO-RE? BTF?

Se você observar praticamente qualquer código eBPF industrial, notará que o arquivo de cabeçalho vmlinux.h é incluído em todos os lugares. Este arquivo contém as definições de todas as estruturas do kernel, como trace_event_raw_sys_enter do exemplo acima, geradas com base no kernel em execução atual.

💡 Este arquivo de cabeçalho pode ser gerado usando o comando:

bash
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

E aqui começa o mais interessante — este arquivo de cabeçalho contém várias linhas especiais tanto no início quanto no fim:

c
#pragma clang attribute push(__attribute__((preserve_access_index)), apply_to = any(record, enum, union))

// ... definições de estrutura ...

#pragma clang attribute pop

Na parte superior de vmlinux.h, você verá a linha __attribute((preserve_access_index)), que informa ao compilador que é necessário adicionar informações de realocação BPF CO-RE (Compile Once – Run Everywhere) para cada campo de estrutura que seu programa eBPF acessa, no arquivo objeto eBPF. Em outras palavras, quando você acessa um campo de estrutura do kernel (por exemplo, filename no exemplo fornecido), o compilador não apenas fixa seu deslocamento. Em vez disso, ele salva metadados — como o nome do campo, seu tipo, deslocamento e estrutura pai — na estrutura bpf_core_relo.

O atributo clang attribute push garante que esta regra se aplique a todas as definições de estrutura até o correspondente clang attribute pop no final do arquivo.

A estrutura de realocação BPF CO-RE (ou, se preferir, informações de realocação) inclui os seguintes campos:

• insn_off: indica a instrução à qual a realocação se aplica, por exemplo, a instrução que define o valor do registro.
• type_id: refere-se aos metadados BTF (BPF Type Format) que descrevem a estrutura da estrutura de kernel de destino.
• access_str_off: especifica como acessar um campo específico em relação à estrutura.

Para o exemplo de tracepoint acima, as informações BTF se parecem com isto:

bash
bpftool btf dump id <prog-btf-id>

Para que seu programa eBPF funcione em diferentes versões do kernel, onde o layout das estruturas pode ser diferente, o kernel de destino também deve ser compilado com suporte a BTF. Sem isso, o programa não conseguirá determinar os deslocamentos de campo corretos em tempo de execução.

Por que isso é necessário?

Quando seu programa eBPF é carregado usando um carregador BPF, como libbpf, o carregador compara os dados BTF do programa com os dados BTF do kernel de destino. Em seguida, ele mapeia os tipos, atualiza os deslocamentos e ajusta o acesso aos campos para que o programa possa ler os dados do kernel corretamente. Este processo é chamado de realocação de deslocamento de campo (field offset relocation).

Uma das limitações não óbvias desta abordagem é que as ferramentas que usam dados BTF dependem implicitamente de que o kernel de destino seja construído com suporte a BTF.

Verifique se o seu kernel tem suporte a BTF:

bash
ls /sys/kernel/btf/vmlinux

Sem suporte a BTF no kernel de destino, o carregador não poderá realizar a realocação de deslocamento de campo e o programa não será carregado ou funcionará incorretamente.

Mas existe alguma maneira de se livrar dessa dependência?

Sim, existe.

Agora vou mostrar como.

A Aqua Security mantém um repositório btfhub-archive, que coleta arquivos BTF prontos para um amplo conjunto de kernels que não contêm BTF integrado. Você pode baixar os arquivos BTF apropriados para os kernels que deseja suportar e incorporá-los diretamente em seu programa eBPF. Isso elimina completamente a necessidade de suporte a BTF no sistema de destino.

Neste ponto, poderíamos parar e mostrar um exemplo simples de como isso é feito, mas eu fui um pouco mais longe. No meu repositório no GitHub, compilei uma solução completa que:

• gera um esqueleto eBPF para meu programa de exemplo
• carrega e incorpora automaticamente dados BTF de btfhub-archive para todas as versões de kernel e sistemas operacionais suportados
• minimiza os dados BTF, deixando apenas os tipos que são realmente usados no programa eBPF de exemplo
• cria um único arquivo executável que pode ser executado em uma ampla gama de kernels sem a necessidade de suporte a BTF no sistema de destino

Adicionei muitos detalhes e comentários úteis ao repositório, então certifique-se de dar uma olhada lá se quiser se aprofundar no assunto ou adaptar esta solução para suas tarefas.

Se você já se deparou com o fato de que o código está vinculado a detalhes específicos do kernel, então é hora de entender não apenas o eBPF, mas também a estrutura do Linux mais profundamente. O curso "Desenvolvimento do Kernel Linux" ajuda a construir esta base na prática: desde a arquitetura do kernel e módulos até estruturas de dados, sincronização, interrupções e gerenciamento de memória. Este é o nível de compreensão que permite trabalhar com confiança com mecanismos de baixo nível e tarefas de sistema complexas.

Faça o teste introdutório para descobrir se o programa do curso é adequado para você. Até 30 de abril, há um desconto de 15% no curso para quem passar no teste com sucesso.

Para se familiarizar com o formato de treinamento e os especialistas, participe das aulas gratuitas:

• 14 de abril, 20:00. "Grafana Stack — fechando todas as necessidades modernas de Observabilidade".
• 21 de abril, 20:00. "Listas encadeadas no kernel Linux: da API ao código real".

Assista a mais aulas de demonstração de professores sobre infraestrutura e muito mais no calendário de eventos.