Fil-C: Basura de entrada, seguridad de memoria de salida [video]

Artículo original ↗ Discusión en Hacker News ↗

Fil-C, una implementación de C segura en memoria que aplica la seguridad en tiempo de ejecución, se está evaluando como alternativa o complemento al modelo de seguridad principalmente en tiempo de compilación de Rust. Los comentaristas debaten hasta dónde llegan las garantías de Fil-C —especialmente en torno a syscalls, data races y `mmap`— frente a lo que Rust y otros lenguajes (Go, C#, TypeScript, Python) ya ofrecen mediante envoltorios seguros, runtimes y herramientas. Muchos ven el valor principal de Fil-C en endurecer grandes bases de código C/C++ existentes con relativamente pocos cambios, mientras cuestionan su sobrecoste de rendimiento, su idoneidad para proyectos nuevos y el encuadre promocional que a veces lo presenta como categóricamente “más seguro” que Rust.

Fil-C vs. Rust: Modelo de seguridad

  • Fil-C y Rust se presentan como enfoques distintos: Rust enfatiza la prevención en tiempo de compilación del comportamiento indefinido; Fil-C enfatiza hacer imposible el comportamiento indefinido en tiempo de ejecución.
  • Algunos argumentan que Rust “prefiere” la verificación estática pero aun así depende de comprobaciones en tiempo de ejecución (comprobaciones de límites, desbordamiento en debug, RefCell, etc.), por lo que se cuestionan las afirmaciones de que previene todo comportamiento indefinido de forma estática.
  • Varios comentarios señalan que los enfoques son complementarios: las comprobaciones en tiempo de ejecución al estilo Fil-C podrían envolver código unsafe de Rust, logrando una “seguridad en profundidad”.

Syscalls, mmap y arquitectura en tiempo de ejecución

  • El “user libc” de Fil-C llama a un runtime de Fil-C que filtra syscalls, las cuales luego pasan por una libc de nivel inferior. La afirmación: los programas de Fil-C son seguros para la memoria hasta el nivel de las syscalls, y las syscalls no pueden escapar de las protecciones (salvo trucos tipo /proc).
  • Un ejemplo clave es mmap: Fil-C expone una API con muchas capacidades de mmap al tiempo que garantiza seguridad de memoria; el subconjunto seguro de Rust no puede ofrecer garantías equivalentes, y el uso de mmap suele ser unsafe.
  • Los críticos responden que Rust también puede tener envoltorios seguros para syscalls, y que ambos sistemas dependen en última instancia de alguna capa insegura.

Código inseguro y fronteras de confianza

  • En Rust, el código unsafe puede aparecer en el código del usuario y en dependencias; la frontera de confianza está controlada por el usuario (y puede restringirse con forbid(unsafe_code) y herramientas).
  • En Fil-C, los programas normales no tienen bloques unsafe; todo el comportamiento inseguro queda confinado al compilador/runtime. Algunos ven esta centralización como estrictamente más segura; otros lo ven como simplemente mover el mismo riesgo.

Data races y límites de la seguridad

  • Se describe a Fil-C como preservando la seguridad de memoria incluso bajo data races; los críticos argumentan que hay escenarios de carrera en los que las propiedades de seguridad se degradan (por ejemplo, acceder a otro objeto mediante un puntero en carrera).
  • Los comentaristas subrayan que errores del kernel y del hardware, trucos de /proc, ptrace, process_vm_writev y mecanismos similares siguen estando fuera de cualquier garantía de seguridad de memoria en espacio de usuario.

Rendimiento, casos de uso y comparaciones

  • Fil-C añade sobrecarga en tiempo de ejecución (aproximadamente comparada con “2x más lento, 4x más memoria” en un comentario), lo que lo hace inadecuado para algunos contextos (por ejemplo, kernels y cierto embebido).
  • Muchos ven su principal valor en endurecer grandes bases de código C/C++ existentes con cambios mínimos; algunos piensan que también puede ser lo bastante rápido para producción en partes del espacio de usuario.
  • Para desarrollo desde cero, los escépticos cuestionan elegir Fil-C frente a lenguajes con GC maduros (Go, C#, TypeScript, Python) que ya proporcionan seguridad de memoria y ecosistemas más ricos.

Comunidad y retórica

  • Varios comentarios señalan un encuadre recurrente de “nosotros vs. ellos” en las discusiones sobre Fil-C, especialmente frente a Rust, y expresan preocupación por afirmaciones exageradas o absolutas (por ejemplo, en torno a la seguridad frente a data races).
  • Otros argumentan que las comparaciones detalladas, incluso adversariales, ayudan a aclarar las concesiones e impulsar una comprensión compartida.