- Criptografia por extensão: diferente do ext4, o btrfs implementa chaves por bloco de dados, permitindo que arquivos criptografados compartilhem espaço via reflinks e snapshots sem duplicar dados.
- Integridade garantida: o sistema calcula checksums sobre o dado já criptografado, garantindo que a proteção contra corrupção de dados (bitrot) funcione mesmo sem a chave de decriptação.
- Novo formato em disco: a versão 6 dos patches altera a estrutura interna, movendo as informações de criptografia para um item de árvore separado, facilitando a limpeza e manutenção do código.
- Limitações temporárias: para garantir estabilidade inicial, o suporte a raid 5/6, envio incremental (btrfs send) e desfragmentação automática estão desabilitados nesta versão.
- Status de desenvolvimento: o código ainda está em fase de revisão (rfc/v6) na lista de discussão do kernel e deve passar por testes rigorosos antes de ser integrado oficialmente.
Daniel Vacek enviou para a lista de discussão do kernel a sexta versão (v6) da implementação do suporte a fscrypt no sistema de arquivos Btrfs. Este é um esforço de longo prazo, desenvolvido em conjunto com Josef Bacik, Omar Sandoval e Sweet Tea Dorminy, que visa trazer para o Btrfs a mesma tecnologia de encriptação transparente utilizada no Android (ext4/f2fs), mas adaptada para a arquitetura única de Copy-on-Write (CoW).
A principal diferença desta versão v6 é uma mudança arquitetural na forma como os dados de criptografia são armazenados no disco, sugerida por desenvolvedores seniores para facilitar a manutenção futura.
Para o iniciante: como a criptografia do Btrfs é diferente?
A maioria dos sistemas de arquivos (como o ext4) criptografa arquivos “por inode” (por arquivo). Se você tem um arquivo, ele tem uma chave. O Btrfs é diferente porque ele suporta “snapshots” e “reflinks” (clonagem). Isso significa que dois arquivos diferentes em pastas diferentes podem apontar para os mesmos blocos de dados no disco para economizar espaço.
Se o Btrfs usasse criptografia por arquivo, clonar um arquivo exigiria descriptografar e criptografar tudo de novo com uma nova chave, o que seria lento e duplicaria o espaço. A solução proposta nestes patches é a criptografia por extensão (per-extent encryption). Cada pedaço de dado (extensão) tem sua própria “identidade” criptográfica, permitindo que ele seja compartilhado entre vários arquivos ou snapshots sem precisar ser reescrito.
O que muda na prática: arquitetura e limitações
A implementação introduz mudanças profundas no fluxo de escrita e leitura para garantir que a integridade dos dados (checksums) funcione corretamente com dados criptografados.
| Recurso | Implementação no Btrfs com fscrypt |
| Chaves de Criptografia | Chaves derivadas por extensão (bloco de dados), e não apenas pelo arquivo. |
| Integridade (Checksum) | O sistema calcula o checksum sobre o dado criptografado (ciphertext). Isso garante que o disco armazena a validação do que está realmente gravado. |
| Formato em Disco (v6) | Introduz um novo item de árvore (BTRFS_FSCRYPT_CTX_KEY). Antes, a info de criptografia ficava anexada ao item do arquivo; agora é um objeto independente para facilitar a remoção. |
| Metadados | Nomes de arquivos são criptografados, mas a estrutura da árvore do sistema de arquivos permanece legível para o kernel. |
Limitações atuais e o que não funciona
Como esta é uma funcionalidade complexa ainda em desenvolvimento, os desenvolvedores desativaram explicitamente certos recursos para garantir a estabilidade nesta fase inicial:
- Sem RAID 5/6: a criptografia está desativada em perfis RAID 5 e 6. O modo como esses perfis reorganizam os dados (bios) entra em conflito com a lógica de criptografia em linha (inline encryption) e checksums.
- Sem ‘btrfs send’: o recurso de envio incremental de backups está desativado. Embora o código já consiga descriptografar nomes de arquivos, a lógica para rastrear renomeações de diretórios em fluxos criptografados ainda não está pronta.
- Sem auto-defrag: a desfragmentação automática foi desligada em arquivos criptografados para evitar a perda de contexto de criptografia durante o processo.
Detalhes da implementação técnica
A série de 43 patches toca em pontos críticos do subsistema de I/O:
- Callback
process_bio: foi adicionado um gancho noblk-cryptopara permitir que o Btrfs processe os dados. Na escrita, o Btrfs calcula o checksum após a encriptação. Na leitura, ele verifica o checksum antes da decriptação. - Separação de Contexto: na versão 5, o contexto de criptografia aumentava o tamanho do
file_extent_item. Na versão 6, cria-se um item de árvore separado. Isso exige cuidado extra: ao deletar uma extensão, o código agora precisa buscar e deletar o item de contexto correspondente. - Suporte a “Nokey”: o patch inclui lógica para lidar com nomes de arquivos “sem chave”. Isso permite que o sistema liste o conteúdo de um diretório criptografado (mostrando nomes embaralhados/hashed) e permita a exclusão de arquivos mesmo sem a chave de descriptografia carregada.
Status de lançamento e disponibilidade
Estes patches (v6) foram enviados para revisão na lista de discussão em 06 de fevereiro de 2026.
- Status atual: em revisão (RFC/Patchset). Ainda não foi mesclado (merged) na árvore principal.
- Próximos passos: a série precisa passar por revisão dos mantenedores do Btrfs e do fscrypt. Daniel Vacek indicou que enviará as atualizações correspondentes para as ferramentas de espaço de usuário (
btrfs-progs) e testes (xfstests) em meados de fevereiro. - Previsão: dado o estágio e a complexidade, é provável que vejamos isso chegar experimentalmente em versões futuras do kernel (talvez 7.1 ou 7.2), mas ainda não está garantido para o ciclo 7.0 imediato.
