Notas de djb sobre o uso do Fil-C

• Fil-C, um novo compilador de C/C++ com segurança de memória, mostra alta compatibilidade com código existente, e a maioria das bibliotecas e aplicações funciona sem modificações
• São fornecidos o procedimento para compilar a partir do código-fonte e instalar o Fil-C no Debian 13, além de um script de instalação automatizada para recompilar glibc e binutils com Fil-C
• Em cerca de 9.000 microbenchmarks de software criptográfico, o Fil-C usa de 1 a 4 vezes mais ciclos que o clang
• Foi tentada a integração com o sistema de build de pacotes do Debian usando Fil-C, com a adição de uma nova ABI (amd64fil0) para permitir a instalação paralela de pacotes baseados em Fil-C
• O Fil-C busca simultaneamente segurança de memória e compatibilidade com o ecossistema existente, mostrando potencial de expansão para sistemas baseados em Debian

---

Visão geral do Fil-C e primeiras impressões

• O Fil-C é um compilador de C/C++ que garante segurança de memória, com alta compatibilidade com código existente
  • A maioria das bibliotecas e aplicações funciona sem modificações
  • Mesmo nos casos excepcionais em que ajustes são necessários, não parece algo difícil de resolver
• O autor tem como objetivo proteger vários sistemas sob sua administração, migrando-os para código compilado com Fil-C
• O ambiente de teste é Debian 13, AMD Ryzen 5 7640HS (6 núcleos, 12 threads), 12 GB de RAM e 36 GB de swap

Materiais e scripts relacionados

• Foi publicado um script de diff para auditoria que compara o Fil-C com os códigos-fonte superiores relacionados (por exemplo, clang e glibc)
• É fornecido o script filian-install-compiler para baixar, compilar e instalar Fil-C, glibc e binutils no Debian 13
  • Tempo total de execução: 86 minutos de tempo real, 477 minutos de tempo de usuário, 52 minutos de tempo de sistema
• Também é fornecido o script filian-install-packages para compilar pacotes-fonte do Debian usando Fil-C
  • Foi confirmado que alguns pacotes (como bzip2) são compilados normalmente
• Foi publicado um gráfico de desempenho Fil-C vs. clang
  • Resultado de cerca de 9.000 microbenchmarks relacionados à criptografia
  • O código compilado com Fil-C consome de 1 a 4 vezes mais ciclos que o clang

Instalação e build do Fil-C

• Após instalar os pacotes necessários com privilégios de root, o build é feito com o usuário sem privilégios filc
• O código-fonte do Fil-C inclui glibc e várias bibliotecas e aplicações de alto nível
• Comando de build: time ./build_all_fast_glibc.sh
  • O musl também pode ser escolhido, mas há incompatibilidades com alguns pacotes (attr, elfutils, sed, vim etc.)
• Quando ocorreu falta de memória durante o build, o problema foi resolvido expandindo o swap para 36 GB
  • Foram usados no pico cerca de 19 GB de swap e 12 GB de RAM
  • Em um servidor grande (128 núcleos, 512 GB de RAM), o build do Fil-C levou 8 minutos e o do musl, 6 minutos

Build de bibliotecas e aplicações adicionais

• O Fil-C inclui o build_all_slow.sh para compilar várias bibliotecas e aplicações
• Foi criado o script build-parallel-20251023.py para paralelizar isso
  • Mesmo com erros, ele continua até concluir todo o build
  • O build em paralelo pode reduzir o tempo total
• No sistema phoenix, 60 de 61 alvos foram concluídos com sucesso (101 minutos de tempo real)
• Apenas o libcap falhou no build (erro ao carregar liblto_plugin.so)
• O util-linux exigiu ajustes relacionados a syscall
• Os demais pacotes principais (attr, bash, curl, openssl, vim etc.) foram compilados sem problemas

Bibliotecas e aplicações adicionais testadas

• boost 1.89.0: em geral funciona normalmente, com necessidade de alguns ajustes relacionados a vfork
• cdb-20251021: funciona normalmente, com diferença nas mensagens de erro em testes artificiais de OOM
• libcpucycles, libgc (substituindo gshim), libntruprime, lpeg, luv etc. foram compilados e testados com sucesso
• Também foi confirmado o funcionamento normal de aplicações CLI importantes como mutt, tig e w3m

Integração com o Debian (Filian)

• Aproveitando a estrutura de multiarquitetura do Debian, foi adicionada uma ABI exclusiva do Fil-C (amd64fil0)
  • Exemplo: apt install bash:amd64fil0 permite instalar a versão compilada com Fil-C
• O Fil-C usa seu próprio diretório em vez de /usr/include, o que causa um problema de divergência no caminho dos arquivos de cabeçalho
  • O script filian-install-compiler ajusta isso para o caminho padrão do Debian
• Foi adicionada ao reconhecimento do Fil-C a compatibilidade nas ferramentas de build do Debian (dpkg-buildpackage, sbuild etc.)
  • Com modificações em /usr/share/dpkg/cputable, config.sub etc.
• O Fil-C e as bibliotecas padrão são colocados em /usr/libexec/fil/amd64
  • Os comandos filcc e fil++ podem ser usados em todo o sistema

Exemplo de build de pacote Debian

• O script auxiliar fillet ajusta símbolos e caminhos de instalação de pacotes-fonte do Debian
• Ao compilar o pacote tinycdb com Fil-C, foram gerados 3 pacotes .deb exclusivos para amd64fil0
  • Após a instalação, os comandos nm e ldd permitem verificar os símbolos do Fil-C (pizlonated_) e os caminhos das bibliotecas
  • Na execução, foi confirmado o funcionamento da proteção de runtime do Fil-C (mensagem indicando bloqueio de violação de “memory safety”)

Build de pacotes Debian adicionais

• libc-dev: foi criado um pacote fictício para resolver dependências
• ncurses: pôde ser compilado e instalado com Fil-C
• libmd: precisou ser recompilado devido a incompatibilidade de versão entre arquiteturas
• readline: exigiu um link simbólico para o caminho dos cabeçalhos
• lua5.4: passou a funcionar normalmente após resolver a dependência de readline

Conclusão

• O Fil-C é uma tentativa de alcançar ao mesmo tempo maior segurança de memória e compatibilidade com o ecossistema existente de C/C++
• Foi demonstrada a viabilidade de build e integração de pacotes no ambiente Debian
• Embora alguns ajustes em scripts de build e caminhos de cabeçalhos ainda sejam necessários, foi garantida a compatibilidade com a maioria dos principais pacotes open source

[GN⁺]

Comentário no Hacker News

• Olhando o benchmark linkado, há casos em que o Fil-C parece mais rápido que C
  Acho que isso provavelmente se deve à variabilidade de microbenchmarks, mas alguns resultados parecem rápidos demais, então fico me perguntando se existe algum problema de correção
• O autor ficou bastante impressionado com o Fil-C e está tentando reconstruir todo o sistema Debian com Fil-C
  Para isso, está criando e compartilhando uma biblioteca shim de GC e scripts de build
• O servidor tinha só 12 GB de swap, então ele precisou reiniciar várias vezes por falta de memória durante a compilação do Fil-C
  Depois de aumentar o swap para 36 GB, o build funcionou normalmente, usando no pico 19 GB de swap + 12 GB de RAM
  Em um servidor com 128 núcleos e 512 GB de RAM, o build do Fil-C levou 8 minutos, enquanto o do musl levou 6 minutos
  Parece que o Fil-C faz bastante análise estática
  • Isso provavelmente é mais o processo de build do próprio LLVM+Clang
• É interessante que a nova versão 64-bit do cdb suporte bancos de dados em escala de exabytes
  Dá para conferir em cdb.cr.yp.to, e foi mencionado que o novo subdomínio cdb usa pqconnect
  • Na prática, cdb.cr.yp.to não tem registro NS, então a estrutura usa DNSCurve
    O pqconnect é usado na etapa de conexão HTTP(S), e ambos codificam chaves públicas no DNS, mas com funções diferentes
    O pqconnect, como o CurveCP, inclui a chave pública em um CNAME
  • Segundo a RFC1034, cdb.cr.yp.to pode ser visto como um subdomínio de cr.yp.to e de yp.to
    Porém, a parte pq1 não é uma chave pública, e sim o hash da chave pública de longo prazo do servidor
  • O uso de pqconnect já existia antes, mas o CNAME de cdb.cr.yp.to parece ter sido adicionado recentemente por volta de 21 de outubro
    As notas relacionadas ao Fil-C foram enviadas há 3 dias
    Thread relacionada
  • Só como referência, houve outra discussão relacionada 11 dias atrás
    Link da discussão anterior
• Acho que é um projeto muito legal
  O objetivo parece ser permitir que a maioria dos programas em C/C++ rode com segurança sem precisar ser reescrita em Rust
  Também fico curioso sobre como a Epic Games entra nessa história
  • O Fil-C é uma linguagem baseada em garbage collection, então é muito mais lento que C
    Em vez de servir para escrever código novo, parece mais adequado para encapsular código existente com segurança, como no caso de sandboxing com WASM
    Ainda assim, o Fil-C detecta crashes com mais precisão
• Fico feliz que o trabalho do Phil finalmente esteja recebendo o reconhecimento merecido
  Parece que há coisas ali que até o modo unsafe do Rust poderia aproveitar
  Em especial, é interessante a forma de fazer linkagem estática de dependências compiladas com Fil-C
  • Mas o Fil-C atualmente não suporta FFI
    Como o Fil-C precisa controlar o programa inteiro para rastrear ponteiros, FFI não combina com a arquitetura
• Foi feita uma curadoria das principais threads sobre Fil-C
  Por exemplo: Fil-C: A memory-safe C implementation,
  Safepoints and Fil-C,
  Fil’s Unbelievable Garbage Collector etc.
  A discussão sobre segurança de memória vem se estendendo entre 2024 e 2025
• Para quem não sabe o que é Fil-C, houve um resumo
  Fil-C é uma implementação com segurança de memória compatível com C/C++, e a maior parte do código compila quase sem modificações
  Todos os erros de memória são detectados como panic, e a segurança é garantida por GC concorrente e InvisiCaps
  Mais detalhes podem ser vistos no site oficial
  • Para usar Fil-C, é preciso aceitar um Garbage Collector em tempo de execução
• É surpreendente que o script build_all_fast_glibc.sh exija 31 GB de memória
  Queria entender o motivo e testar o Fil-C por conta própria
  • Isso acontece porque o processo de build e linkedição do LLVM é pesado
• É curioso ver um criptógrafo famoso usando bash e curl
  • Na verdade, curl | bash às vezes pode ser aceitável
    Texto relacionado