Greg K-H: «Escribir código nuevo en Rust beneficia a todos»
(lore.kernel.org)Por qué se debe introducir Rust en el kernel de Linux
- Con base en la experiencia de haber revisado casi todas las correcciones de bugs y problemas de seguridad del kernel de Linux durante los últimos 15 años, quiere hablar sobre la necesidad de adoptar Rust
- No todas las correcciones de bugs se reflejan en el árbol de versiones estables, pero en general las importantes sí, y él está en una posición en la que revisa todos los CVE del kernel
Limitaciones de C y ventajas de Rust
- La mayoría de los bugs que ocurren en el kernel de Linux provienen de limitaciones estructurales del lenguaje C
- En particular, hay muchos bugs causados por errores simples, y este tipo de problemas casi no ocurren en Rust
- Sobrescritura de memoria (Rust no detecta todos los casos, pero puede resolver una parte considerable)
- Problemas de limpieza en rutas de error
- Omisión en la verificación de valores de error
- Bugs de use-after-free (uso después de liberar)
- Si se introduce Rust en el kernel, desarrolladores y mantenedores pueden dejar atrás estos errores básicos y concentrarse en los problemas realmente difíciles (errores lógicos, condiciones de carrera, etc.)
También se debe seguir manteniendo la base de código existente en C
- Actualmente el kernel de Linux está compuesto por más de 30 millones de líneas de código en C, y es imposible reemplazarlo por Rust en el corto plazo
- Por eso, el trabajo de reforzar la seguridad del código C que impulsan desarrolladores como Kees y Gustavo es indispensable y debe continuar
- Lo ideal no es que Rust reemplace el código existente, sino escribir el código nuevo (especialmente drivers) en Rust para reducir problemas
La seguridad de API que ofrece Rust
- Rust permite diseñar las API internas del kernel para que sean más seguras y fáciles de usar
- En la actualidad, las API del kernel basadas en C son complejas, propensas a errores y muchas veces requieren una revisión minuciosa por parte de los mantenedores
- Por ejemplo, hay varias formas de usar con seguridad estructuras como
struct cdev, y se necesita mucha experiencia para aprovecharlas correctamente - Con Rust se pueden definir las API con mayor claridad, por lo que se puede reducir de forma importante la posibilidad de que los desarrolladores cometan errores
- Esto no beneficia solo a quienes usan Rust, sino que también ayuda a quienes trabajan con el código existente en C
Respuesta a las preocupaciones sobre la dificultad de adoptar Rust
- Rust no es una solución mágica → pero sí puede resolver una parte considerable de los problemas actuales
- Aumento de la carga para los mantenedores → pero los desarrolladores que quieren introducir Rust son quienes están haciendo directamente ese trabajo
- Dificultad de mantener una base de código mixta → pero el kernel de Linux ya ha resuelto problemas mucho más difíciles hasta ahora
Conclusión
- Linux es una herramienta que innumerables desarrolladores de todo el mundo usan para resolver problemas, y
- ahora si existe una demanda de desarrolladores que quieren escribir código seguro para hardware, no se debe ignorar
- El modelo de desarrollo de Linux ha crecido a una escala que nadie había imaginado y ha demostrado una capacidad de ingeniería sobresaliente
- Ahora es momento de avanzar con la adopción de Rust para impulsar los próximos 20 años o más de desarrollo
Debemos aceptar nuevas tecnologías e ideas y esforzarnos para que puedan tener éxito junto con la comunidad.
24 comentarios
La adopción de Rust probablemente sea un cambio difícil de evitar si se considera la seguridad de memoria. Imagino que intentarán recomponer la situación mediante algún compromiso razonable.
Pero, en lo personal, siento que las palabras clave de Rust no se me quedan bien a la vista, y cuando vuelvo a verlas mucho tiempo después tampoco las recuerdo con facilidad, así que me cuesta terminar de agarrarle la mano ;;;; Entiendo que todas son necesarias, pero a veces se siente como memorizar a la fuerza los verbos irregulares del inglés. Aun así, también es cierto que los resultados escritos en Rust tienden a causar menos problemas en el entorno real.....
Me cuesta pensar que merezca tanto rechazo el no querer incluir en el kernel un lenguaje que todavía no ha madurado. Si ahora mismo te piden buscar gente a tu alrededor que maneje Rust con soltura, ¿acaso no son poquísimos? Creo que no sería tarde incluirlo cuando el lenguaje haya madurado un poco más y también haya suficientes usuarios, aunque no sean tantos como los de los lenguajes legacy.
Creo que la utilidad del lenguaje Rust puede demostrarse suficientemente incluso sin que se aplique al kernel de Linux.
Aunque sorprende que Rust, incluso al nivel de madurez que tiene hoy, siga siendo llamado un "lenguaje todavía inmaduro", aparte de eso, me pregunto si de verdad merece tanta crítica intentar reducir el peso de lenguajes inseguros dentro del kernel. Si lo pensamos, ¿de verdad hay tanta gente a nuestro alrededor capaz de escribir código seguro en C con la soltura suficiente como para contribuir al kernel? Más que seguir esperando una mayor madurez de C, parece que este es justamente el momento adecuado, ahora que ya están bien establecidas las exigencias de una nueva era.
Rust ya es útil, y su intención de entrar al kernel probablemente no sea para demostrar esa utilidad.
Cuando decidieron introducir Rust por primera vez, imagino que debe haber habido discusiones al respecto.
Si piensas cuál grupo es más grande, si el de expertos en C o el de expertos en Rust, claramente C supera por mucho.
También da la impresión de que, para un programador que ya tiene todo el conocimiento del dominio, aprender un lenguaje más no debería ser algo tan grande,
pero el nivel de dominio que exigen quienes trabajan con el kernel ya sería otro tema...
Esta opinión también está bien.
No entiendo en absoluto la afirmación de que debería hacer un fork e irse. ¿Por qué demonios Linus tendría que hacer un fork y salir de Linux?
¿Hay alguien diciéndole a Linus que haga un fork y se vaya? Como no he visto a nadie decir eso en esta discusión...
Yo también soy usuario de Rust, pero si se mezcla código Rust con código C en un proyecto open source, a menos que exista una política estricta sobre hasta dónde se permite el uso de Rust, me parece que se volvería imposible de controlar o, como mínimo, subirían muchísimo los costos de revisión y mantenimiento; por eso creo que la decisión más sensata es hacer un fork en lugar de agregarlo.
No sé mucho del kernel, pero creo que estaría bien si se pudiera traducir automáticamente el código en C a Rust. Claro, además del problema de traducir el código, también estaría el factor humano.
Si hay tanta gente que quiere introducir Rust en el kernel, ¿no podrían bifurcarlo e irse a un proyecto nuevo? Luego, cuando madure lo suficiente, las principales distribuciones podrían cambiarse a un kernel basado en Rust.
No entiendo muy bien por qué están peleando entre ustedes.
No sé bien qué debería decirle porque no sé si usted tiene experiencia en desarrollo del kernel.
Antes que nada, aplicar el lenguaje Rust no significa cambiar el kernel a Rust. Se podría decir que entonces bastaría con separarlo y crear otro kernel, pero
la idea no es hacer el kernel en Rust, sino crear wrappers en Rust solo para las interfaces del kernel destinadas a los controladores de dispositivos, de modo que únicamente los controladores de dispositivos
puedan desarrollarse en Rust. Por eso, irse a un proyecto nuevo no tiene sentido.
No he desarrollado del lado de Linux.
Parece que el wrapper en Rust para los controladores de dispositivo tiene una estructura que no puede separarse del kernel...
Resulta bastante irónico que la comunidad de Linux, que venía justificando un tono tóxico en nombre de la estabilidad del kernel, ahora considere razonable responder con "si no te gusta, haz un fork".
No soy parte de la comunidad de Linux, pero...
No creo que se deba considerar a esas personas y a quien escribió este comentario como parte de la misma comunidad.
Parece que hay un punto difícil de prever: si el resultado del fork terminará siendo una migración o una era de reinos combatientes.
Incluso después de hacer el fork, reflejar los cambios de upstream no parece que vaya a ser una situación muy agradable.
https://es.news.hada.io/topic?id=16860
Viendo que el fork de Realtime Linux se integró después de 20 años, quizá no habría que decidir a la ligera hacer un fork.
Yo me refería a esto.
Las funciones en tiempo real pudieron mantenerse durante mucho tiempo como un proyecto separado del kernel, y quien las necesitara podía tomarlas, aplicarlas al kernel y usarlas.
Aunque soy usuario de Rust, me impresionó el comentario de hgwxx7_ publicado en r/rust1.
Recuerdo que, cuando era necesario hacer backport a la versión estable o por algo así y me ponía en contacto, incluso en medio de todo ese trabajo respondía muy bien.
"Rust no es la respuesta correcta, pero está más cerca de la respuesta correcta que Java y Python" -codemaster kimc-
Opiniones en Hacker News
¿No se pueden denunciar este tipo de comentarios de odio?
Estoy de acuerdo.