Bugs de falta de solidez de hace 11 años encontrados en el comprobador de préstamos de Rust

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

Se ha encontrado un error de solidez de hace 11 años en el comprobador de préstamos de Rust, en el que se acepta incorrectamente código aparentemente normal que involucra tiempos de vida y una implementación personalizada de `Drop`, permitiendo que una referencia sobreviva a los datos a los que apunta. Los comentaristas analizan cómo esto viola la promesa central de Rust de seguridad de memoria, subrayan que es un error de implementación del compilador y no un fallo del sistema de tipos del lenguaje, y señalan que parece requerir un destructor rebuscado para convertirse en un exploit real. El incidente alimenta un debate más amplio sobre cuán “seguro” es realmente Rust frente a C, los límites de cualquier sistema de tipos o prueba formal, y el papel creciente de herramientas (incluida la IA) para descubrir errores sutiles del compilador.

Naturaleza del error

  • Falta de solidez en el comprobador de préstamos alrededor de T: 'static y Drop.
  • Ejemplo mínimo: una struct genérica Q<T: 'static>(Option<T>) con una implementación de Drop también limitada por 'static.
  • El compilador permite incorrectamente almacenar una referencia no &'static (por ejemplo, &l con tiempo de vida de la pila) en Q, que se supone que solo debe contener datos 'static.
  • El destructor puede entonces tratar esto como 'static, por ejemplo, guardándolo en una variable global, lo que habilita un uso después de liberar memoria.

Por qué pasó desapercibido

  • El patrón que lo desencadena se considera inusual: necesita un Drop personalizado además de límites de tiempo de vida en una configuración específica.
  • Debate sobre cuán “normal” es Drop personalizado: algunos dicen que es raro, otros que es común, especialmente con FFI; pero este patrón exacto es raro.
  • Muchos programas con tiempos de vida inválidos pueden no fallar visiblemente nunca, así que el error pudo ejercitarse sin un fallo obvio.

Garantías de seguridad, solidez y UB

  • Aclaración:
    • Falta de solidez = Rust seguro puede causar UB debido a fallos del compilador/comprobador de tipos.
    • UB en la especificación = el usuario se sale del comportamiento bien definido.
  • Este error está en el compilador, no en las reglas de tiempos de vida previstas por Rust; la solución es rechazar ese código.
  • Algunos señalan que hay muchos problemas abiertos de falta de solidez; otros destacan que las correcciones pueden publicarse incluso en versiones de parche, y que el código afectado nunca fue “Rust válido”.

Comparaciones con C y otros lenguajes

  • Algunos usan esto para argumentar que el marketing de seguridad de Rust está exagerado o da una falsa sensación de seguridad.
  • Otros responden que C/C++ también tienen fallos del compilador además de una UB a nivel de lenguaje muy extendida, así que Rust sigue representando una mejora enorme en seguridad.
  • Se discute que ningún lenguaje puede ser perfectamente seguro; el objetivo es hacer que clases de errores sean imposibles o extremadamente raras.

Métodos formales e IA

  • Referencias a esfuerzos en curso para especificar o demostrar formalmente Rust o subconjuntos de Rust.
  • Reconocimiento de que incluso asistentes de prueba, especificaciones y las matemáticas subyacentes pueden estar equivocados, así que las garantías absolutas son imposibles.
  • Algunos ven a la IA/LLMs como herramientas prometedoras para fuzzing o búsqueda de errores en compiladores; otros son escépticos o están cansados del entusiasmo por la IA.

Dinámica comunitaria y social

  • Quejas sobre el proselitismo de Rust y la percepción de ataques a otros lenguajes, frente a defensas que dicen que el mensaje oficial es más medido.
  • Metadiscusión sobre reacciones exageradas ante errores individuales: algunos piden perspectiva: este es un defecto real pero estrecho, no un fracaso total del modelo de Rust.