Resumo

  • A RFC 9669 padroniza a codificação e os grupos de conformidade da ISA BPF; ela não transforma host, runtime alternativo e hardware de offload em um único alvo.
  • Um programa aceito no host ainda precisa provar compatibilidade, carga, vínculo, invocação e efeito no caminho em que de fato será executado.

O canário passou no host. O objeto carregou, recebeu ID e incrementou o contador esperado. A automação então habilitou a variante com offload, usando a mesma etiqueta de capacidade: “BPF suportado”.

A placa recusou o plano. O conjunto opcional de operações e o contrato de funções expostos naquele destino não coincidiam com os do kernel. O sistema voltou ao host, mas o painel manteve o rótulo “offload ativo”.

A ISA comum permitiu comparar as duas realidades. Ela não as tornou iguais.

Um vocabulário comum não é uma capacidade universal

A RFC 9669 define instruções BPF básicas de 64 bits e instruções largas de 128 bits. Campos de opcode, registradores, offset e valor imediato carregam semântica segundo a classe. Compiladores e runtimes ganham uma descrição comum da operação, inclusive para extensões governadas.

O documento não exige todas as instruções de todos os implementadores. base32 é obrigatório; grupos adicionais são opcionais. base64 inclui base32, atomic64 inclui atomic32, e divmul64 inclui divmul32. Declarar suporte a um grupo significa implementar todas as instruções dele.

Os registros IANA tornam essa declaração verificável como especificação. O registro de grupos preserva nome, descrição, inclusões, exclusões, status, controlador e referência. O registro de instruções associa padrões de campos a uma descrição e aos grupos correspondentes. Uma extensão cria um grupo sucessor em vez de ampliar silenciosamente um grupo já registrado.

Nada disso mede a máquina instalada. Permanent é o status da atribuição, não uma ordem para cada runtime. O host pode implementar um grupo que a placa não oferece. Duas placas podem expor limites distintos. Uma configuração pode desabilitar uma função presente no código. A descoberta precisa identificar destino, versão, arquitetura e momento.

Programar contra “BPF” sem registrar os grupos exigidos é como programar contra o nome de uma linguagem sem conhecer sua versão e suas bibliotecas. O nome coordena; a seleção concreta ainda pertence ao operador.

A ISA termina antes da política de admissão

Instruções reconhecidas não garantem um programa válido. Os saltos contam offsets em unidades de instrução de 64 bits. Cair no segundo word de uma instrução larga de 128 bits produz comportamento indefinido. O erro nasce da composição, não da ausência de um opcode no registro.

Mapas, variáveis e chamadas de função adicionam dependências de plataforma. A RFC descreve operações abstratas, mas a resolução concreta e a superfície de funções vêm da documentação do ambiente. Program types diferentes podem admitir contextos e helpers diferentes, mesmo no mesmo kernel.

A RFC 9669 diz que verificadores são responsáveis por terminação, acesso seguro à memória, contratos de API e comportamento indefinido. Os detalhes ficam fora do seu escopo. Essa separação conserva uma ISA portável sem congelar toda política de segurança ou toda interface local.

No Linux, o verificador confere o fluxo de controle e depois explora caminhos possíveis, rastreando tipos e valores de registradores e posições da pilha. Callbacks ajustam o acesso ao contexto e os protótipos permitidos por program type. Um endereço pode caber numericamente e ainda falhar por tipo, alinhamento ou limite.

A documentação de projeto reconhece a consequência operacional: para saber se o verificador aceitará um programa, tente carregá-lo. A promessa de compatibilidade do Linux para programas antes aceitos é uma propriedade dessa evolução; não deve ser estendida automaticamente a outro runtime ou offload.

Testar no host não testa o destino de offload

Um fluxo de implantação precisa tratar host e hardware como classes separadas. Para cada uma, registrar grupos declarados, funções e objetos disponíveis, limites do verificador, resultado da relocação, log de rejeição e identidade do objeto criado. Se houver fallback, o painel deve dizer qual caminho está executando, não apenas que a política permanece “disponível”.

Depois da carga vêm vínculo e invocação. Um program ID prova que existe um objeto. Um link prova uma associação com um hook. Nenhum dos dois prova que eventos passaram por ali. O contador de invocação fecha essa lacuna, mas continua interno ao mecanismo.

O resultado externo pede outra fonte. Para uma política de encaminhamento, um fluxo de teste deve ser observado antes e depois do ponto de decisão. Para uma política de aplicação, a transação precisa mostrar seu estado durável. Um mapa BPF pode registrar a decisão pretendida e ainda não observar um caminho paralelo.

A assinatura também não resolve as etapas seguintes. A documentação atual do Linux afirma que assinatura é ortogonal a permissões e ao verificador. BPF_SIG_VERIFIED num hook inicial significa assinatura válida, não programa carregado. É um exemplo Linux, não um requisito da RFC 9669, e demonstra como recibos fortes permanecem estreitos.

Fallback sem identidade produz uma falsa continuidade

Quando o offload falha e o host assume, há uma mudança operacional. Latência, capacidade, caminho de observação e risco podem mudar. Se o sistema preserva apenas o nome da policy, a continuidade aparente esconde a troca de executor.

O recibo deve incluir hash do objeto, destino, grupo, versão, program type, veredicto, program ID, link, hook, map generation, modo host/offload, motivo do fallback, invocações e evidência externa. Também deve manter o estado negativo: grupo ausente, função indisponível, rejeição, attach incompleto ou zero invocações.

Rollback exige enumerar links em ambos os destinos. Carregar uma versão antiga no host não desativa necessariamente a placa. Remover o objeto offload não prova que todo tráfego voltou. Gerações e observação do caminho real são parte do controle.

A contribuição da RFC 9669 é permitir que essas diferenças sejam expressas sem ambiguidade. A decisão local continua necessária: qual conjunto opcional aceitar, que verificador confiar, onde executar e qual resultado considerar suficiente.

Fontes