La falta de seguridad en hilos de la stdlib de C y el fracaso de Rust seguro

• Un fallo que solo ocurría en ARM64

  • Durante el proceso de portar el código de I/O de red de EdgeDB de Python a Rust, surgió un problema en el que las pruebas fallaban de forma intermitente en los runners de CI con ARM64.
  • Al principio parecía un deadlock, pero en realidad el proceso se estaba cerrando por un crash y el runner de pruebas no lograba detectarlo.

• Teoría inicial

  • Para entender por qué el problema ocurría solo en ARM64, se consideraron las diferencias en el modelo de memoria.
  • El modelo de memoria de Intel es estricto, mientras que ARM tiene un modelo de memoria más débil.

• Depuración en la máquina de CI

  • Se conectaron directamente al runner ARM64 en AWS para investigar el problema.
  • El proceso se cerraba por un crash y dejaba un core dump, que se analizó para identificar la causa del problema.

• La causa real: setenv y getenv

  • setenv no es seguro en entornos multihilo y puede provocar crashes al interactuar con getenv.
  • Se descubrió que la reasignación de variables de entorno era la causa del problema.

• Conexión con openssl_probe

  • El problema ocurría cuando openssl-probe configuraba las variables de entorno SSL_CERT_FILE y SSL_CERT_DIR.
  • El crash se producía durante el proceso en que rust-native-tls de Rust configuraba esas variables de entorno.

• Por qué solo ocurrió en ARM64 Linux

  • El crash solo ocurre cuando coinciden varias condiciones, entre ellas la cantidad de variables de entorno y fallos de I/O.

• Solución

  • Se decidió cambiar del backend rust-native-tls/openssl de reqwest a rustls.
  • El proyecto Rust planea volver inseguras las funciones de configuración del entorno, y el proyecto glibc mejorará la seguridad de getenv en entornos multihilo.

[carnoxen]

setenv no es thread-safe y C no quiere corregirlo

La función setenv está causando problemas otra vez.

[y15un]

Yo pondría el título como: "La falta de seguridad para hilos de la stdlib de C es algo que ni Rust, por muy seguro que sea, puede remediar". :)

[halfenif]

Lo entendí claramente.

[GN⁺]

Comentarios de Hacker News

• En la próxima edición de Rust, los modificadores del entorno pasarán a ser inseguros. Esto podría afectar a crates que provoquen conflictos

  • En la biblioteca estándar de Rust, set_var y remove_var requerirán usar un bloque unsafe {} en la edición 2024
  • La documentación actual menciona los problemas de seguridad, pero originalmente fue un error hacer seguras estas funciones

• Un parche para glibc hizo que getenv fuera más seguro, pero C todavía permite acceso directo al entorno, así que no es completamente seguro

  • Los mantenedores de la biblioteca estándar de C se resisten a hacer setenv seguro para multihilo, pero como mínimo debería definirse una nueva API segura para hilos
  • El mantenedor de Musl no está convencido de que este problema no pueda resolverse

• Sufrir bugs relacionados con el entorno en Linux se considera casi un rito de paso

  • Linus y el kernel son prácticos para corregir bugs de POSIX, pero glibc sigue rezagado
  • Haber ofrecido getenv_r(), sincronizarlo con setenv() y emitir advertencias al compilar/enlazar habría ayudado a resolver el problema

• La configuración mediante variables de entorno formó parte del movimiento de las "12-factor app", pero parece un método tonto

  • Se considera mejor usar archivos de configuración como YAML en lugar de variables de entorno

• Las máquinas de CI que corren en Amazon AWS tienen la ventaja de ofrecer un usuario root real

  • Parece que se ha perdido la capacidad de compilar y depurar código localmente sin nube ni contenedores

• Es un gran artículo que profundiza en un bug poco intuitivo

  • Estos reportes detallados de resolución de problemas ofrecen la experiencia más cercana a hacerlo uno mismo

• env::set_var ahora es inseguro

  • En programas de un solo hilo, puede llamarse de forma segura
  • En Windows, siempre es seguro tanto en programas de un solo hilo como multihilo
  • En programas multihilo de otros sistemas operativos, la única opción segura es no usar set_var ni remove_var

• Hace recordar una experiencia en la que setproctitle no funcionaba en cierta base de código

  • Después de importar numpy, setproctitle dejó de funcionar porque la dirección de environ cambió debido a una llamada a getenv o setenv durante la inicialización de numpy