Se ha publicado la versión 1.81 del lenguaje de programación de propósito general Rust, originalmente desarrollado por Mozilla, pero ahora mantenido por la organización sin fines de lucro Rust Foundation. El lenguaje está enfocado en la seguridad de la gestión de memoria y ofrece herramientas para lograr un alto paralelismo en la ejecución de tareas, sin necesidad de un recolector de basura ni de un runtime (el runtime se limita a la inicialización básica y al mantenimiento de la biblioteca estándar).
Los métodos de manejo de memoria en Rust eliminan los errores del desarrollador al manipular punteros y protegen contra problemas que surgen del trabajo de bajo nivel con la memoria, como el acceso a áreas de memoria después de su liberación, desreferenciación de punteros nulos, desbordamientos de búfer, etc. Para la distribución de bibliotecas, la gestión de dependencias y la construcción de proyectos, se está desarrollando el administrador de paquetes Cargo. Para alojar bibliotecas, se soporta el repositorio crates.io.
La seguridad en el manejo de la memoria se garantiza en Rust en tiempo de compilación a través de la verificación de referencias, el seguimiento de la propiedad de los objetos, la gestión de tiempos de vida de objetos (ámbitos) y la evaluación de la corrección del acceso a la memoria durante la ejecución del código. Rust también ofrece herramientas para protegerse contra desbordamientos enteros, requiere la inicialización obligatoria de los valores de las variables antes de su uso, maneja mejor los errores en la biblioteca estándar, aplica el concepto de inmutabilidad de referencias y variables por defecto, y ofrece una fuerte tipificación estática para minimizar errores lógicos.
Novedades principales:
- Se ha estabilizado el rasgo core::error::Error, que define las descripciones de error que se muestran. Este cambio permite usar un único rasgo Error en diferentes bibliotecas, independientemente del entorno, incluidas las bibliotecas que no están vinculadas a la biblioteca estándar y que utilizan el atributo «#![no_std]».
- Las funciones de ordenamiento estables y no estables en la biblioteca estándar se han traducido para utilizar nuevos algoritmos, que demuestran una mayor velocidad de operación y un menor tiempo de compilación. En la implementación de los nuevos algoritmos de ordenamiento se garantiza la detección de rasgos Ord mal definidos y, en tales casos, se produce un error (panic) en lugar de datos agrupados aleatoriamente.
- En el linter se ha implementado un nuevo nivel de verificación «expect» («#[expect(lint)]»), que permite asegurarse de que se realiza la verificación y que se emite una advertencia si la verificación no se cumple (debido a un error en la implementación o a la desactivación de la verificación). Por ejemplo, al migrar la base de código para usar la verificación undocumented_unsafe_blocks a través de Clippy, se puede especificar «#[expect(clippy::undocumented_unsafe_blocks)]» para asegurarse de que durante el proceso de transición todos los bloques unsafe estén documentados. Clippy también ha implementado las verificaciones clippy::allow_attributes y clippy::allow_attributes_without_reason, que simplifican la sustitución de atributos «#[allow]» por «#[expect(lint)]».
- Se ha proporcionado la posibilidad de documentar la razón de los reemplazos de los niveles de verificación (lint), brindando a los nuevos desarrolladores información sobre las razones de agregar dicha verificación, que se muestra como un mensaje del compilador. Por ejemplo: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
- Se ha trasladado un nuevo lote de API a la categoría estable, incluyendo la estabilización de métodos e implementaciones de traits:
- core::error
- hint::assert_unchecked
- fs::exists
- AtomicBool::fetch_not
- Duration::abs_diff
- IoSlice::advance
- IoSlice::advance_slices
- IoSliceMut::advance
- IoSliceMut::advance_slices
- PanicHookInfo
- PanicInfo::message
- PanicMessage
El signo «const», que define la posibilidad de uso en cualquier contexto en lugar de constantes, se aplica en funciones:
- char::from_u32_unchecked (función)
- char::from_u32_unchecked (método)
- CStr::count_bytes
- CStr::from_ptr
El tipo std::panic::PanicInfo ha sido renombrado a std::panic::PanicHookInfo (el uso del nombre antiguo se mantendrá, pero a partir de la siguiente versión su uso generará una advertencia). Por otro lado, core::panic::PanicInfo permanecerá como está, pero se desarrollará como un tipo separado. La separación de tipos permitirá implementar diferentes métodos específicos para su ejecución en el contexto de snd y no_std.
- Se ha completado la transición al ABI C-unwind (‘extern «C-unwind»‘), que se diferencia del ABI sin el sufijo «-unwind» (‘extern «C»‘) en la preservación del comportamiento seguro (safe), si el proceso de ‘desenrollado’ (unwinding) iniciado por una falla del programa o generación de excepciones al estilo C++ cruza el límite del ABI (por ejemplo, cuando una excepción que ocurre en el código de un lenguaje de programación, al desenrollar, toca la pila asociada al código de otro lenguaje de programación). A partir de la versión 1.81 de Rust, el ABI ‘extern «C»‘ incluye el manejo de errores ante un desenrollado no manejado.
- Se ha implementado un tercer nivel de soporte para las plataformas i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Este tercer nivel implica soporte básico, pero sin pruebas automatizadas, publicación de versiones oficiales y verificación de la capacidad de compilar el código.
- Se ha implementado un segundo nivel de soporte para las plataformas de destino loongarch64-unknown-linux-musl y arm64ec-pc-windows-msvc. Este segundo nivel de soporte garantiza la capacidad de compilación.
- Para los sistemas Linux en la plataforma LoongArch se proporciona un conjunto de herramientas completo y un perfilador.
- Se ha corregido una vulnerabilidad (CVE-2024-43402) en std::process::Command, que se manifiesta solo en la plataforma Windows y que elimina la vía de explotación de una vulnerabilidad anteriormente corregida, BatBadBut, relacionada con el manejo de caracteres especiales al usar las llamadas Command::arg y Command::args, diseñadas para pasar argumentos directamente al proceso, sin tratarse a través de un intérprete de comandos. En la práctica, al ejecutar scripts bat y cmd, se ejecutaba el proceso cmd.exe, que tiene su propia lógica de separación de argumentos. La forma de eludir esta protección se basa en que Windows elimina espacios y puntos iniciales en las rutas, es decir, un archivo con la extensión «.bat. .» se procesa como «.bat».
Además, se puede señalar la salida de Wedson Almeida Filho del puesto de mantenedor del proyecto Rust for Linux, que se encarga de la incorporación de herramientas para desarrollar en el lenguaje Rust al núcleo de Linux. Tras la salida de Wedson, aún quedan dos mantenedores en el proyecto: Miguel Ojeda, autor y principal desarrollador del proyecto Rust-for-Linux, y Alex Gaynor, exdirector de la Python Software Foundation, quien se ha pasado a promover Rust. El mantenedor que se fue, quien se unió al proyecto hace 4 años, es empleado de Microsoft y autor de un controlador experimental que implementa el sistema de archivos EXT2, escrito en Rust. Últimamente, el trabajo de Almeida se había centrado en crear herramientas para desarrollar sistemas de archivos en Rust. Este año, Almeida aportó 17 commits al repositorio de Rust-for-Linux (en comparación, Miguel Ojeda añadió 53 commits).
Como razón de su salida, se menciona la falta de energía y entusiasmo que una vez tuvo para responder a algunas tonterías no técnicas. Según Almeida, los desarrolladores se ven obligados a gastar mucha energía en disputas sobre cuestiones insignificantes que socavan un objetivo global más importante. Almeida sigue creyendo que el futuro del núcleo depende del uso de lenguajes que aseguren un manejo seguro de la memoria, y si la comunidad de desarrolladores de Linux no lo entiende, Linux será desplazado por otro núcleo, como alguna vez le ocurrió a Unix.
Los defensores del proyecto Rust-for-Linux se han enfrentado a la necesidad de superar la resistencia de los veteranos desarrolladores del núcleo, que no ven la necesidad de aprender un nuevo lenguaje. En su carta de renuncia, Almeida menciona como ejemplo una discusión que tuvo lugar durante la presentación de Almeida y Kent Overstreet en la conferencia 'Linux Storage, Filesystem, Memory-Management, and BPF Summit', que se centró en el uso de Rust para el desarrollo de sistemas de archivos. Ted Ts'o, autor de los sistemas de archivos ext2/ext3/ext4, criticó la actividad de adoptar Rust, comparando la iniciativa Rust-for-Linux con un intento de obligar a todos a aceptar la religión de Rust.
En respuesta a la intención de Almeida de crear un envoltorio sobre las interfaces de sistemas de archivos escritas en C para su uso en código en Rust, Ted Ts'o señaló que tal envoltura inevitablemente provocará problemas, ya que cualquier cambio en las interfaces de C y la realización de refactorizaciones requerirá cambios en la envoltura para Rust, y él no quiere asumir la responsabilidad adicional de corregir los problemas que surjan en el código en Rust y de seguir el estado de la envoltura de Rust. El código en C está en constante evolución y si sus cambios rompen la funcionalidad de la envoltura para Rust, esto afectará a todos los sistemas de archivos vinculados a esa envoltura.
Ted también considera que en un futuro cercano la envoltura para Rust seguirá siendo secundaria y que la aparición de problemas en los enlaces será un dolor de cabeza solo para los desarrolladores de Rust-for-Linux, y no para la comunidad de desarrolladores de sistemas de archivos en el núcleo. Se indicó que no todos los desarrolladores planean aprender Rust, y por lo tanto, después de realizar cambios que afectan a otro código, solo podrán actualizar el código dependiente en C, pero no podrán corregir las envolturas de Rust, ya que no conocen Rust. A la discusión también se unió James Bottomley, que supervisa la subestructura SCSI, quien comentó que cuanta más semántica se codifica en los envoltorios, más frágiles se vuelven en términos de asegurar la sincronización.
Mientras tanto, la empresa Google, que el año pasado reescribió en Rust el firmware pvmfm, utilizado en máquinas virtuales, que se ejecutan en la plataforma Android, compartió su experiencia sobre cómo incorporar gradualmente código en Rust en firmware existente, originalmente escrito en C o C++. Se demostró cómo se puede aumentar considerablemente la seguridad del firmware al crear componentes de reemplazo funcionalmente idénticos, escritos en Rust. Se sugiere que al implementar Rust, se preste atención al uso de Rust para nuevo código y código que realice funciones críticas desde el punto de vista de la seguridad (por ejemplo, código para procesar datos externos de fuentes no confiables). Para la integración de código en Rust y C, se propone utilizar capas (shim) que traduzcan las llamadas entre API en Rust y C (la API de C se exporta para su uso en código Rust y viceversa), lo que permite reescribir gradualmente los elementos de la API en Rust.
Fuente: opennet.ru
