Kops: Safely Extending the eBPF Compilation Pipeline with Native Operations

Resumo Técnico: Kops – Estendendo com Segurança o Pipeline de Compilação de eBPF com Operações Nativas

1. Definição do Problema

O eBPF (Extended Berkeley Packet Filter) estende o kernel do SO de forma segura para redes, observabilidade e segurança, empregando um pipeline de compilação onde um verificador dentro do kernel checa os programas em busca de segurança antes que um compilador JIT (Just-In-Time) os traduza para código nativo. No entanto, o JIT do kernel é projetado para ser simples e confiável, traduzindo instruções de bytecode uma a uma em uma única passagem. Esse design "por-opcode" impede otimizações entre instruções e falha em reconhecer idiomas de hardware (ex: rotação, seleção condicional) que CPUs modernas executam como instruções únicas.

A caracterização no artigo revela que programas eBPF rodam até 1,98× mais devagar em ARM64 e 1,57× mais devagar em x86-64 comparados ao código nativo. A lacuna de desempenho é impulsionada principalmente pela incapacia do JIT do kernel de otimizar sequências de múltiplas instruções em padrões nativos eficientes. As soluções existentes são limitadas: adicionar otimizações diretamente ao JIT do kernel é difícil devido aos longos ciclos de lançamento, à necessidade de aceitação no upstream e à expansão da Base de Computação Confiável (TCB). Otimizadores de userspace (ex: Merlin, K2) podem reescrever o bytecode, mas não podem emitir instruções nativas fora do conjunto de instruções padrão do eBPF.

2. Metodologia: O Mecanismo Kops

Os autores apresentam o Kops, uma interface de extensão que permite que compiladores de userspace e módulos de kernel introduzam novas operações sem modificar o núcleo do kernel. O Kops opera sob o princípio de representação dupla para cada nova operação:

1. Sequência de Prova (Proof Sequence): Uma sequência de instruções eBPF puras (vanilla) que o verificador existente no kernel checa. Isso garante que as garantias de segurança (segurança de memória, terminação) permaneçam intactas.
2. Emissão Nativa (Native Emit): Uma emissão direta de instruções de máquina pelo compilador JIT.

Fluxo de Trabalho:

• Reconhecimento: Um reconhecedor em tempo de compilação (em userspace) identifica padrões correspondentes às operações suportadas (ex: uma sequência específica de shifts e ORs para uma rotação) e os reescreve em "instruções estendidas".
• Verificação: Ao carregar, o verificador reduz a instrução estendida de volta à sua sequência de prova (eBPF puro) e realiza sua análise de segurança padrão.
• Restauração e Execução: Se a verificação passar, o JIT restaura a instrução estendida e a despacha para um descritor que fornece o código de máquina nativo para a arquitetura específica.

Restrições e Segurança:

• As mudanças no núcleo do kernel são mínimas e genéricas.
• O verificador permanece independente de arquitetura; ele apenas vê a sequência de prova.
• A Base de Computação Confiável (TCB) é expandida apenas pelo código de emissão nativa específico para cada operação. O reconhecedor e as sequências de prova não fazem parte da TCB; se um erro no reconhecedor produzir uma reescrita insegura, o verificador a rejeitará.
• Verificação Formal: Os autores utilizam o Lean 4 para provar que, para cada operação, a emissão nativa produz o mesmo estado arquitetural visível ao eBPF que a sequência de prova.

3. Principais Contribuições

• Mecanismo Kops: Um framework para estender o pipeline de compilação do eBPF com novas operações, reutilizando o verificador existente para segurança. Ele separa a prova de segurança (eBPF puro) da otimização de desempenho (emissão nativa).
• Implementação EInsn: Uma instanciação concreta do Kops fornecendo sete operações de idioma de hardware (Rotação, Seleção Condicional, Extração de Bits, Troca de Bytes, Prefetch, Cópia em Massa e LEA). Essas operações mapeiam para instruções nativas únicas em x86-64 e ARM64, onde o conjunto padrão do eBPF exige múltiplas instruções.
• Provas Formais: Provas em Lean 4 verificando a equivalência semântica entre as sequências de prova e as emissões nativas para cada operação EInsn, garantindo que as garantias do verificador se transfiram para o código otimizado.
• Implementação no Kernel: Uma adição de 929 linhas ao núcleo do Linux (cobrindo a redução/restauração do verificador, despacho do JIT e registro) e um reconhecedor de tempo de compilação em userspace.

4. Resultados

A avaliação foi conduzida em x86-64 e ARM64 usando 27 microbenchmarks de bytecode puro e aplicações de produção (Cilium e Katran).

• Desempenho de Microbenchmark:
  • x86-64: O EInsn alcançou até 24% de aceleração (1,242×) sobre o JIT original do kernel, recuperando 42% da lacuna de desempenho para o código nativo.
  • ARM64: O EInsn alcançou até 22% de aceleração (1,222×).
  • Tamanho do Código: O tamanho do código nativo diminuiu de 12–23%.
• Aplicações de Produção:
  • Cilium (x86-64): O throughput melhorou em 7,4% (1,074×).
  • Katran (ARM64): O throughput melhorou em 7,3% (1,073×).
• Overhead: O overhead de tempo de carga foi insignificante (razão da média geométrica de 0,99× em relação ao kernel padrão).
• Sensibilidade de Política: O estudo destacou que habilitar cegamente todos os locais correspondentes nem sempre produz o desempenho ideal; uma política de "lucratividade" (selecionando famílias baseadas em ganhos específicos de carga de trabalho) é mais eficaz do que maximizar a cobertura.
• Comparação de Limite Superior: Os autores compararam o EInsn contra uma abordagem "nativo-no-kernel" (confiando em todo o código nativo da aplicação). Embora a abordagem nativa tenha alcançado 2,358× de aceleração no Cilium, ela exigia confiar no código nativo da aplicação, ampliando significamente a TCB. O EInsn ocupa um meio termo, oferecendo acelerações controladas sem confiar no binário completo da aplicação.

5. Significância e Alegações

O artigo afirma que o Kops aborda com sucesso as limitações de desempenho do JIT do eBPF sem comprometer seu modelo de segurança ou ampliar significativamente a TCB. Ao desacoplar a prova de segurança (eBPF puro) da otimização de desempenho (emissão nativa), o Kops permite a introdução de idiomas específicos de hardware que eram anteriormente impossíveis de utilizar com segurança dentro do kernel.

Os autores enfatizam que esta abordagem evita a necessidade de modificações no JIT do kernel upstream ou revisões do conjunto de instruções. Em vez disso, novas operações são entregues como módulos de kernel carregáveis. O trabalho demonstra que um conjunto pequeno e delimitado de idiomas de hardware pode recuperar uma parte significativa da lacuna de desempenho entre eBPF e nativo, tornando o eBPF uma opção mais viável para tarefas de kernel de alto desempenho e baixa latência, mantendo as rigorosas garantias de segurança exigidas para a execução no kernel.