Uma nova proposta para o Kernel Linux visa fortalecer o BPF como ferramenta de segurança, introduzindo um novo tipo de mapa chamado BPF_MAP_TYPE_CRED_STORAGE. A ideia é permitir que programas BPF LSM anexem dados de estado diretamente às credenciais de um processo (struct cred), com o kernel gerenciando automaticamente o ciclo de vida desses dados. Em outras palavras: quando as credenciais “nascem”, o storage nasce junto; quando elas morrem, o storage é limpo — tudo de forma automática. A série de patches (v2), enviada por David Windsor em 12 de setembro de 2025, traz a implementação do mapa, novas kfuncs (bpf_cred_storage_get/delete) e selftests cobrindo o ciclo de vida das credenciais. É trabalho em andamento, mirando uma janela de merge futura (provavelmente 6.18 ou posterior), não algo aceito no mainline.
Para visualizar o benefício, pense que cada processo no sistema carrega um “crachá” (struct cred) com suas permissões. O novo mapa permite que um programa de segurança BPF “cole um post-it” nesse crachá com informações extras — por exemplo, “este processo acessou um arquivo sensível às 14:32”. Quando o processo termina e o crachá é destruído, o post-it é automaticamente descartado. Esse local storage sob medida promete reduzir vazamentos de estado e simplificar políticas mais sofisticadas, como rastrear atividades ao longo do tempo ou detectar padrões que se estendem por múltiplas chamadas de LSM. Os selftests do patch verificam justamente isso: criação, acesso e persistência dos dados ao longo dos eventos de preparo/commit e liberação de credenciais.
O debate da comunidade: local storage vs. hash maps
A proposta, porém, não passou sem questionamentos — e é aqui que a história fica interessante para quem acompanha Linux BPF security. Em respostas públicas, Song Liu pediu que o patch explicite por que um novo tipo de local storage é realmente necessário. O argumento de Song: sistemas normalmente não criam um número explosivo de struct cred, então um hash map “pequeno” indexado por ponteiro de credencial poderia ser suficiente — e até mais rápido — desde que o programa BPF remova as entradas no momento certo (por exemplo, em cred_free).
Alexei Starovoitov, mantenedor do BPF, foi mais direto: “tecnicamente possível, mas assim não”. Para ele, cred não justifica acesso ultrarrápido nem requer gerenciamento automático de ciclo de vida; a orientação é usar um hash map com struct cred * como chave. Além disso, Alexei revelou um ponto crucial: os mapas de local storage existentes sofrem hoje de um “performance cliff” — um degrau de performance — que precisa ser resolvido antes de expandir essa técnica para mais objetos do kernel. Em suma, mesmo que a ideia faça sentido conceitual, há uma dívida técnica de performance que impede “copiar e colar” o padrão para novas estruturas como credenciais.
Windsor, por sua vez, defendeu que o local storage traz uma vantagem de correção difícil de replicar com hash maps: o gerenciamento automático evita “entradas obsoletas” — um risco real porque struct cred pode ser clonada em prepare_creds e trocada em commit_creds antes da liberação da original. Em cenários em que a política precisa “seguir” a credencial ao longo desse vai-e-vem, a cola automática do local storage parece mais confiável (e menos propensa a vazios temporais) do que um hash map manualmente higienizado. Ainda assim, diante da preocupação com performance e das diretrizes do mantenedor, o autor reconheceu que alternativas — como embrulhar rhashtable em um novo tipo de mapa — podem ser um caminho pragmático enquanto a comunidade investiga e corrige o tal “cliff”.
O que isso significa na prática para políticas de LSM baseadas em BPF
Para quem escreve políticas com BPF LSM, a proposta acena com um modelo mais limpo de estado por processo: vincular decisões e “históricos” diretamente às credenciais, que são a identidade de execução do processo em chamadas sensíveis (acesso a arquivos, mudanças de UID, operações de rede protegidas etc.). Em termos práticos, o BPF_MAP_TYPE_CRED_STORAGE permitiria:
- associar um valor por credencial — por exemplo, um carimbo de tempo da última ação sensível — sem gerenciar manualmente o nascimento e a morte dessa entrada;
- inicializar dados durante
cred_preparee validar ou consolidar durantecred_free, com selftests já exercitando esse fluxo; - reduzir as chances de “vazamento” de entradas de mapa quando processos têm credenciais de vida curta ou se reautenticam com frequência.
Ao mesmo tempo, o debate deixa duas mensagens claras. Primeiro: não é feature aceita — é uma proposta (v2) que depende de consenso técnico; a discussão de arquitetura (e performance) vai guiar os próximos passos. Segundo: mesmo quem simpatiza com o design precisa encarar o custo/benefício na realidade atual do BPF — especialmente à luz do performance cliff nos local storages e da alternativa relativamente simples de um hash map com limpeza em hooks como cred_free. Em outras palavras, o futuro do cred storage vai depender tanto do “por quê” (correção e ergonomia) quanto do “como” (custos e efeitos colaterais).
Panorama e próximos passos
Como toda boa mudança no kernel, a proposta nasceu em patches, ganhou selftests e agora vive no escrutínio da lista — com feedback de quem mantém e perfila o BPF diariamente. Há um fio condutor: LSMs clássicos (como SELinux, AppArmor, Landlock) sempre dependeram de blobs ligados a objetos-chave (credenciais, inodes, arquivos). O esforço do BPF é alcançar essa mesma capacidade de maneira segura e performática, sem reinventar rodas que já giram no kernel. A questão central — local storage versus hash map para struct cred — é menos sobre “poder” e mais sobre “dever”: qual abordagem equilibra correção, simplicidade e performance hoje? O consenso ainda não chegou, mas a conversa está andando — que é exatamente como o Linux evolui.
