Absolutistas de la seguridad de memoria

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

La seguridad de memoria en la programación de sistemas está en el centro de un debate acalorado entre defensores de las garantías en tiempo de compilación de Rust y partidarios de Fil-C y enfoques similares con comprobación en tiempo de ejecución para código C/C++ heredado. Los comentaristas sopesan las compensaciones entre modelos de seguridad más estrictos, sobrecarga de rendimiento, ruptura del ecosistema y ergonomía para el desarrollador, señalando que Rust es “en su mayor parte seguro” pero aún depende de `unsafe` y FFI, mientras que Fil-C puede endurecer bases de código existentes a costa de la velocidad. Muchos argumentan que la elección del lenguaje debería guiarse por objetivos prácticos de seguridad y fiabilidad en lugar de “guerras de lenguajes” tribales, y que herramientas como la verificación formal y la comprobación de modelos pueden importar tanto como el propio lenguaje.

La seguridad de memoria como objetivo y sus límites

  • Muchos sostienen que la seguridad de memoria debería ser una expectativa predeterminada, especialmente para software de uso amplio y cualquier cosa que maneje entrada no confiable (códecs, TLS, navegadores, sistemas operativos).
  • Otros señalan que los incidentes del mundo real suelen estar impulsados más por la ingeniería social, los ataques a la cadena de suministro, los errores lógicos y los problemas de configuración que por la corrupción de memoria.
  • Varios comentarios subrayan: la seguridad de memoria es necesaria pero ni de lejos suficiente; otras clases de errores (p. ej., fallos lógicos/de diseño al estilo Log4Shell) siguen existiendo.

Rust, Fil-C/Zig, lenguajes con GC

  • Rust es elogiado por combinar alto rendimiento, un sistema de tipos sólido, un modelo de propiedad y buenas herramientas; muchos dicen que su valor va mucho más allá de “C++ pero seguro”.
  • Fil-C se ve como atractivo para añadir seguridad a C/C++ existentes con comprobaciones fuertes en tiempo de ejecución, a costa del rendimiento y de fallos en lugar de rechazos en compilación.
  • Algunos sostienen que Fil-C puede ser estrictamente “más seguro” (sin trampas de escape), mientras que Rust y los lenguajes con GC tienen bordes unsafe/FFI; otros responden que esta es una distinción teórica si unsafe es raro y está bien contenido.
  • Algunos prefieren Zig y C por su expresividad a nivel de puntero y su control de bajo nivel, pese a los riesgos reconocidos.

Seguridad en compilación frente a seguridad en ejecución

  • Las garantías de Rust en tiempo de compilación se valoran por su fiabilidad y por requerir menos depuración; los esquemas solo en tiempo de ejecución se ven como convertir UB en fallos, lo cual es mejor pero sigue siendo doloroso.
  • Otros priorizan “capturado en cualquier lugar” sobre “capturado en compilación”, y aceptan comprobaciones en tiempo de ejecución, punteros gordos o mecanismos al estilo Fil-C.

C/C++ heredados y alternativas

  • Los grandes ecosistemas heredados (kernels, toolchains, pilas GUI, APIs de GPU) hacen irrealista “reescribir todo en Rust/GC”, lo que motiva Fil-C y enfoques similares.
  • Algunos lamentan la negativa histórica de C/C++ a estandarizar construcciones más seguras (p. ej., slices/spans con comprobaciones de límites) pese a décadas de experiencia con lenguajes de memoria segura.

Herramientas de seguridad, SO/hardware y métodos formales

  • La comprobación de modelos, el análisis estático y la verificación formal (CBMC, Kani, WUFFS, compiladores/SO verificados) se presentan como complementarios o superiores a las soluciones centradas solo en el lenguaje.
  • Problemas de hardware como rowhammer y los bits volteados (mitigados pero no eliminados por ECC) muestran que “lenguaje seguro para memoria” ≠ “memoria físicamente segura”.

Guerras de lenguajes y cultura

  • Muchos se muestran frustrados por el tribalismo entre Rust, Fil-C y Zig y por el encuadre ideológico (“woke vs anti-woke”, proselitismo de aire moralista).
  • Varios piden debates pragmáticos, específicos de cada dominio, en lugar de posiciones absolutistas de “el único lenguaje verdadero”.