Fil-C: Lixo Entra, Segurança de Memória Sai [vídeo]

Artigo original ↗ Discussão no Hacker News ↗

Fil-C, uma implementação de C segura em relação à memória que aplica segurança em tempo de execução, está sendo avaliado como alternativa ou complemento ao modelo de segurança predominantemente em tempo de compilação do Rust. Comentadores debatem até onde vão as garantias do Fil-C — especialmente em torno de syscalls, data races e `mmap` — em contraste com o que Rust e outras linguagens (Go, C#, TypeScript, Python) já oferecem por meio de wrappers seguros, runtimes e ferramentas. Muitos veem o principal valor do Fil-C em reforçar grandes bases de código C/C++ existentes com relativamente poucas mudanças, ao mesmo tempo em que questionam seu overhead de desempenho, sua adequação a novos projetos e o enquadramento promocional que às vezes o apresenta como categoricamente “mais seguro” que Rust.

Fil-C vs. Rust: Modelo de Segurança

  • Fil-C e Rust são apresentados como abordagens distintas: Rust enfatiza a prevenção em tempo de compilação de comportamento indefinido; Fil-C enfatiza tornar o comportamento indefinido impossível em tempo de execução.
  • Alguns argumentam que Rust “prefere” a verificação estática, mas ainda depende de verificações em tempo de execução (verificações de limites, overflow em debug, RefCell, etc.), então são contestadas as alegações de que ele previne todo comportamento indefinido estaticamente.
  • Vários comentários observam que as abordagens são complementares: verificações em tempo de execução no estilo Fil-C poderiam ser aplicadas sobre código unsafe de Rust, produzindo “segurança em profundidade”.

Syscalls, mmap e Arquitetura de Runtime

  • As chamadas de “user libc” do Fil-C entram em um runtime do Fil-C que filtra syscalls, que então passam por uma libc de nível inferior. A alegação: programas Fil-C são seguros em relação à memória até o nível das syscalls, e as syscalls não podem escapar das proteções (salvo truques do tipo /proc).
  • Um exemplo importante é mmap: o Fil-C expõe uma API com muitas capacidades de mmap enquanto garante segurança de memória; o subconjunto seguro do Rust não pode oferecer garantias equivalentes, e o uso de mmap normalmente é unsafe.
  • Críticos respondem que Rust também pode ter wrappers seguros para syscalls, e que ambos os sistemas, no fim das contas, dependem de alguma camada unsafe.

Código unsafe e Fronteiras de Confiança

  • Em Rust, código unsafe pode aparecer no código do usuário e em dependências; a fronteira de confiança é controlada pelo usuário (e pode ser apertada com forbid(unsafe_code) e ferramentas).
  • No Fil-C, programas comuns não têm blocos unsafe; todo comportamento inseguro fica confinado ao compilador/runtime. Alguns veem essa centralização como estritamente mais segura; outros veem isso apenas como deslocar o mesmo risco.

Data Races e Limites da Segurança

  • O Fil-C é descrito como preservando a segurança de memória mesmo sob data races; críticos argumentam que há cenários de race em que as propriedades de segurança se degradam (por exemplo, acessar outro objeto por meio de um ponteiro racy).
  • Comentadores enfatizam que bugs de kernel e hardware, truques com /proc, ptrace, process_vm_writev e mecanismos semelhantes continuam fora de qualquer garantia de segurança de memória em espaço de usuário.

Desempenho, Casos de Uso e Comparações

  • O Fil-C adiciona overhead de tempo de execução (aproximadamente comparado a “2x mais lento, 4x memória” em um comentário), o que o torna inadequado para alguns contextos (por exemplo, kernels, alguns sistemas embarcados).
  • Muitos veem o principal valor em reforçar grandes bases de código C/C++ existentes com mudanças mínimas; alguns acham que ele também pode ser rápido o suficiente para produção em partes do espaço de usuário.
  • Para desenvolvimento greenfield, céticos questionam escolher Fil-C em vez de linguagens maduras com GC (Go, C#, TypeScript, Python), que já oferecem segurança de memória e ecossistemas mais ricos.

Comunidade e Retórica

  • Vários comentários observam a recorrente divisão “nós contra eles” nas discussões sobre Fil-C, especialmente em comparação com Rust, e expressam preocupação com alegações exageradas ou absolutas (por exemplo, sobre segurança contra data races).
  • Outros argumentam que comparações detalhadas, até mesmo adversariais, ajudam a esclarecer trade-offs e a melhorar o entendimento compartilhado.