Notas de djb sobre el uso de Fil-C

• Fil-C, un nuevo compilador de C/C++ con seguridad de memoria, muestra alta compatibilidad con el código existente, y la mayoría de las bibliotecas y aplicaciones funcionan sin modificaciones
• Se ofrece el procedimiento para compilar e instalar desde el código fuente Fil-C en Debian 13, junto con un script de instalación automática para recompilar glibc y binutils con Fil-C
• En cerca de 9000 microbenchmarks de software criptográfico, Fil-C usa entre 1 y 4 veces más ciclos que clang
• Se intenta integrar Fil-C en el sistema de construcción de paquetes de Debian, agregando una nueva ABI (amd64fil0) para permitir la instalación en paralelo de paquetes basados en Fil-C
• Fil-C busca al mismo tiempo seguridad de memoria y compatibilidad con el ecosistema existente, y muestra potencial para expandirse a sistemas basados en Debian

---

Resumen de Fil-C e impresiones iniciales

• Fil-C es un compilador de C/C++ que garantiza seguridad de memoria y muestra alta compatibilidad con el código existente
  • La mayoría de las bibliotecas y aplicaciones funcionan sin modificaciones
  • Incluso en los casos excepcionales donde se requieren cambios, no parecen difíciles de resolver
• El autor busca proteger varios sistemas bajo su administración migrándolos a código compilado con Fil-C
• El entorno de prueba es Debian 13, AMD Ryzen 5 7640HS (6 núcleos, 12 hilos), 12 GB de RAM y 36 GB de memoria swap

Material relacionado y scripts

• Se publica un script de diff para auditoría que compara las diferencias entre Fil-C y fuentes superiores relacionadas (por ejemplo, clang, glibc)
• Se ofrece el script filian-install-compiler para descargar, compilar e instalar Fil-C, glibc y binutils en Debian 13
  • Tiempo total de ejecución: 86 minutos de tiempo real, 477 minutos de usuario y 52 minutos de sistema
• Se ofrece el script filian-install-packages para compilar paquetes fuente de Debian usando Fil-C
  • Se confirmó la compilación correcta de algunos paquetes (como bzip2)
• Se publica una gráfica de rendimiento de Fil-C vs. clang
  • Resultados de cerca de 9000 microbenchmarks relacionados con criptografía
  • El código compilado con Fil-C consume entre 1 y 4 veces más ciclos que clang

Instalación y compilación de Fil-C

• Tras instalar los paquetes necesarios con privilegios de root, la compilación se realiza con el usuario sin privilegios filc
• El código fuente de Fil-C incluye glibc y varias bibliotecas y aplicaciones de alto nivel
• Comando de compilación: time ./build_all_fast_glibc.sh
  • También se puede elegir musl, pero existe incompatibilidad con algunos paquetes (attr, elfutils, sed, vim, etc.)
• Cuando hubo falta de memoria durante la compilación, se resolvió ampliando el espacio swap a 36 GB
  • Se usaron como máximo alrededor de 19 GB de swap y 12 GB de RAM
  • En un servidor grande (128 núcleos, 512 GB de RAM), la compilación de Fil-C tomó 8 minutos y la de musl 6 minutos

Compilación de bibliotecas y aplicaciones adicionales

• Fil-C incluye build_all_slow.sh para compilar varias bibliotecas y aplicaciones
• Se escribió el script build-parallel-20251023.py para paralelizar ese proceso
  • No se detiene ante errores y continúa con toda la compilación
  • La compilación en paralelo permite reducir el tiempo
• En el sistema phoenix, 60 de 61 objetivos se completaron con éxito (101 minutos de tiempo real)
• Solo libcap falló al compilar (error al cargar liblto_plugin.so)
• util-linux requiere modificaciones relacionadas con syscalls
• El resto de los paquetes principales (attr, bash, curl, openssl, vim, etc.) se compiló sin problemas

Bibliotecas y aplicaciones adicionales probadas

• boost 1.89.0: en general funciona bien, aunque requiere algunos cambios relacionados con vfork
• cdb-20251021: funciona correctamente, con diferencias en los mensajes de error en pruebas artificiales de OOM
• libcpucycles, libgc (reemplazo de gshim), libntruprime, lpeg, luv y otros se compilaron y probaron correctamente
• También se confirmó el funcionamiento correcto de aplicaciones CLI importantes como mutt, tig y w3m

Integración con Debian (Filian)

• Aprovecha la estructura multiarquitectura de Debian para agregar una ABI exclusiva para Fil-C (amd64fil0)
  • Por ejemplo, con apt install bash:amd64fil0 se puede instalar una versión compilada con Fil-C
• Fil-C usa su propio directorio en lugar de /usr/include, lo que provoca un problema de desajuste en las rutas de archivos de cabecera
  • El script filian-install-compiler ajusta esto a la ruta estándar de Debian
• Se añade reconocimiento de la arquitectura Fil-C en herramientas de construcción de Debian (dpdk-buildpackage, sbuild, etc.)
  • Se modifican /usr/share/dpkg/cputable, config.sub y otros archivos
• Fil-C y las bibliotecas estándar se colocan en la ruta /usr/libexec/fil/amd64
  • Los comandos filcc y fil++ pueden usarse globalmente en el sistema

Ejemplo de compilación de paquetes Debian

• El script auxiliar fillet ajusta los símbolos y las rutas de instalación de paquetes fuente de Debian
• Al compilar el paquete tinycdb con Fil-C, se generaron 3 paquetes .deb exclusivos para amd64fil0
  • Tras la instalación, se verifican con los comandos nm y ldd los símbolos de Fil-C (pizlonated_) y las rutas de bibliotecas
  • Al ejecutarlo, se confirma que funciona la protección del runtime de Fil-C (se muestra un mensaje que bloquea una infracción de “memory safety”)

Compilación de paquetes Debian adicionales

• libc-dev: se crea un paquete falso para resolver dependencias
• ncurses: puede compilarse e instalarse con Fil-C
• libmd: requiere recompilación por desajustes de versión entre arquitecturas
• readline: requiere un enlace simbólico para la ruta de cabeceras
• lua5.4: funciona correctamente tras resolver la dependencia con readline

Conclusión

• Fil-C es un intento de lograr al mismo tiempo mayor seguridad de memoria y compatibilidad con el ecosistema existente de C/C++
• Queda demostrada la posibilidad de compilar e integrar paquetes en un entorno Debian
• Aunque se necesitan algunos ajustes en scripts de compilación y rutas de cabeceras, se asegura compatibilidad con la mayoría de los principales paquetes de código abierto

[GN⁺]

Comentarios en Hacker News

• Al ver el benchmark enlazado, hay casos en los que Fil-C parece ser más rápido que C.
  Probablemente se deba a la variabilidad de los microbenchmarks, pero algunos resultados se ven demasiado rápidos y eso hace preguntarse si hay un problema de exactitud
• El autor está bastante impresionado con Fil-C y está intentando reconstruir todo el sistema Debian con Fil-C.
  Para ello, está creando y compartiendo una biblioteca shim de GC y scripts de compilación
• El servidor solo tenía 12 GB de swap, así que tuvo que reiniciar varias veces por falta de memoria durante la compilación de Fil-C.
  Al aumentar el swap a 36 GB, la compilación funcionó con normalidad, y llegó a usar un máximo de 19 GB de swap + 12 GB de RAM.
  En un servidor con 128 núcleos y 512 GB de RAM, compilar Fil-C tomó 8 minutos, y musl 6 minutos.
  Parece que Fil-C realiza mucho análisis estático
  • Eso probablemente corresponda al proceso de compilar LLVM+Clang en sí
• Resulta interesante que la nueva versión de 64 bits de cdb admita bases de datos de escala exabyte.
  Se puede revisar en cdb.cr.yp.to, y se menciona que el nuevo subdominio de cdb usa pqconnect
  • En realidad, cdb.cr.yp.to no tiene un registro NS, así que la estructura hace que funcione DNSCurve.
    pqconnect se usa en la etapa de conexión HTTP(S), y aunque ambos codifican claves públicas en DNS, cumplen funciones distintas.
    pqconnect, al estilo de CurveCP, incluye la clave pública en el CNAME
  • Según RFC1034, cdb.cr.yp.to puede considerarse un subdominio de cr.yp.to y de yp.to.
    Sin embargo, la parte pq1 no es una clave pública, sino el hash de la clave pública de largo plazo del servidor
  • El uso de pqconnect ya existía desde antes, pero el CNAME de cdb.cr.yp.to parece haber sido agregado recientemente alrededor del 21 de octubre.
    Las notas relacionadas con Fil-C se enviaron hace 3 días.
    Hilo relacionado
  • Como referencia, también hubo una discusión relacionada hace 11 días.
    Enlace a la discusión anterior
• Me parece un proyecto genial.
  La meta parece ser que la mayoría de los programas en C/C++ puedan ejecutarse de forma segura sin necesidad de reescribirlos en Rust.
  También da curiosidad cómo entra Epic Games en todo esto
  • Fil-C es un lenguaje basado en recolección de basura, así que es mucho más lento que C.
    Más que para escribir código nuevo, parece adecuado para envolver código existente de forma segura, como con el sandboxing de WASM.
    Aun así, Fil-C detecta los crashes con más precisión
• Me alegra que el trabajo de Phil por fin esté recibiendo el reconocimiento que merece.
  Parece que también podría haber ideas útiles para el modo unsafe de Rust.
  En particular, es interesante la forma de enlazar estáticamente dependencias compiladas con Fil-C
  • Sin embargo, Fil-C actualmente no soporta FFI.
    Como Fil-C necesita controlar todo el programa para rastrear punteros, FFI no encaja bien a nivel estructural
• Se recopilaron los principales hilos sobre Fil-C.
  Por ejemplo: Fil-C: A memory-safe C implementation,
  Safepoints and Fil-C,
  Fil’s Unbelievable Garbage Collector, entre otros.
  La discusión sobre seguridad de memoria entre 2024 y 2025 sigue en marcha
• Para quienes no saben qué es Fil-C, aquí va un resumen.
  Fil-C es una implementación con seguridad de memoria compatible con C/C++, y la mayor parte del código compila casi sin cambios.
  Todos los errores de memoria se detectan como panic, y la seguridad se garantiza con GC concurrente e InvisiCaps.
  Se puede ver una explicación más detallada en el sitio oficial
  • Para usar Fil-C, en tiempo de ejecución hay que aceptar el Garbage Collector
• Sorprende que el script build_all_fast_glibc.sh requiera 31 GB de memoria.
  Da curiosidad saber por qué, y dan ganas de probar Fil-C directamente
  • Eso se debe a que la compilación y el enlazado de LLVM son pesados
• Es curioso ver a un criptógrafo famoso usando bash y curl
  • En realidad, curl | bash a veces puede estar bien.
    Artículo relacionado