Las cosas se están oxidando en Kernelland

Ganando impulso en torno a la idea de agregar Rust al kernel de Linux. ¿Por qué exactamente es esto importante y qué significa para el resto? El kernel de Linux fue solo C y ensamblaje a lo largo de su vida. Un gran proyecto como el core tiene muchas herramientas en común en torno a la operación de sus lenguajes, por lo que agregar otro es bastante difícil. También existe la cultura del proyecto desarrollada en torno a la elección del idioma. Entonces, ¿por qué exactamente las barbas grises del desarrollo central incluso consideran la idea de agregar Rust? Para responder en una línea, es porque C fue diseñado en 1971 para ejecutarse en las minicomputadoras de Bell Labs. Si quieres pegarte un tiro en el pie, C te entregará el arma cargada.

Por otro lado, si desea escribir un núcleo, C es un gran lenguaje para la codificación de bajo nivel. ¿Memoria de acceso directo? Sí. Asamblea en línea? Por supuesto. ¿Trabaja directamente en el metal, sin recolección de basura o máquinas virtuales en el camino? Absolutamente. Pero todas las cosas que hacen que C sea excelente para la programación central también hacen que C sea peligroso para la programación central.

Ahora escucho que sus teclados colectivos hacen clic con consternación: "¡Es posible escribir código C seguro!" Sí, sí es posible. Es muy fácil estropearlo, y cuando lo estropeas en un núcleo, tienes vulnerabilidades de seguridad. También hay algunas cosas que son objetivas. terrible sobre C, como un comportamiento indefinido. Los compiladores C hacen todo lo posible para hacer lo correcto con un maldito código como i++ + i++; o a[i] = i++;. Pero es casi seguro que eso no hará lo que usted quiere, y peor aún, tal vez algunas veces hacer lo correcto.

Rust parece estar ganando popularidad. Hay algunos proyectos ambiciosos, como reescribir corolarios en Rust. Muchas otras aplicaciones estándar reciben la reescritura de Rust. Es bastante inevitable que la colección de desarrolladores de Rust comenzara a preguntar, ¿podríamos invadir el kernel más tarde? Esto se presentó para la Conferencia de Plomeros de Linux, y la respuesta de la lista de correo fue cautelosamente optimista. Si se pudiera agregar Rust sin romper las cosas y sin perder las mismas cosas que hacen que Rust sea útil, entonces sí, sería interesante.

¿Por qué se oxida?

Entonces, ¿qué hace que Rust sea tan interesante? Hay dos respuestas principales aquí. Primero, es un lenguaje moderno con una fuerte garantía de seguridad en la memoria. (Hay una advertencia aquí, y cubriremos algunos códigos inseguros más adelante). Aproximadamente dos tercios de todas las vulnerabilidades de seguridad son el resultado de correcciones de errores, y Rust casi las elimina. Una segunda ventaja, Rust tiene algunos de los placeres que hemos llegado a apreciar en los lenguajes modernos como fáciles de usar. STRING escriba integrado en la biblioteca estándar y algunas características útiles para escenarios comunes como la comparación de cadenas.

La otra respuesta es que Rust es fácil con el código C y la programación del kernel. Rust hace su magia en el compilador. El código que escribe es lo que realmente funciona, sin un intérprete o un recolector de basura que intente ayudar. Rust no tuvo una sobredosis de patrones orientados a objetos, pero encaja bien con las estructuras de estilo C que ya se utilizan en el núcleo. Incluso el modelo de pila es muy similar a C.

Hay un problema con la garantía de seguridad de la memoria de Rust: es imposible escribir un kernel que sea formalmente seguro para la memoria. Kernel tiene que escribir en la memoria no asignada, hacer cálculos matemáticos extraños y otras cosas aparentemente extrañas para que nuestras computadoras funcionen. Esto no funciona bien con un lenguaje que intenta garantizar que las manipulaciones de la memoria sean seguras. Entonces, ¿cómo se escribe el código central con Rust? Rust agregó el unsafe palabra clave, lo que permite el uso de acceso directo a la memoria y otras técnicas similares que no funcionan con las garantías de memoria de Rusts. Mantén juntos los problemas potenciales y facilita la revisión.

Hay al menos otro lenguaje que puede venir a la mente como una actualización incremental a C que intenta hacer algunas de estas cosas: C ++. Seguramente esto sería aún más apropiado, ¿verdad? Los desarrolladores del kernel tienen fuertes opiniones sobre esta idea. Para decirlo suavemente, ninguna de las mejoras en C ++ es útil en el contexto del kernel, y algunos de los otros cambios simplemente se ven obstaculizados.

¿Cuál es el plan?

Entonces, ¿veremos el núcleo completamente reescrito en Rust? No es probable. El proceso de desarrollo central es cuidadosamente conservador, por lo que la introducción inicial de Rust se realizará de la manera menos intrusiva posible: el código del controlador. Como subcomandante central [Greg Kroah-Hartman] dijo, "los controladores son probablemente el primer lugar para una prueba como esta porque son las 'hojas finales' del árbol de dependencia en la fuente central. Dependen de la funcionalidad central, pero nada depende de ellos".

En la práctica, esto significaría que el kit de herramientas, la documentación y el código de muestra se fusionarían inmediatamente en el kernel. En algún momento en el futuro, una de las partes interesadas, como Google, comenzaría a escribir nuevos controladores en Rust. Google parece estar muy interesado en convertir partes de Android a Rust, probablemente en un intento de evitar que su sistema operativo siga funcionando a partir de las similitudes del grupo NSO. Hay un controlador de ejemplo útil en Rust en el blog de seguridad de Google. Otro enlace interesante es que [Miguel Ojeda], programador jefe del esfuerzo de Rust for Linux, ahora trabaja a tiempo completo en Prossimo para este propósito. Prossimo es un brazo del Grupo de Investigación de Seguridad de Internet, que también es famoso por liderar Let's Encrypt. Fundado por [Ojeda]Se proporcionó el trabajo de Google.

Entonces, ¿dónde estamos ahora? La versión 6 de los chips Rust acaba de enviarse a la lista de correo central. Ha habido algunas solicitudes de cambios pequeños, pero especialmente los desarrolladores han comenzado a exigir que los parches se inserten en el kernel 5.19 después de que se abra la ventana de combinación. 5.18-rc6 acaba de ser lanzado, por lo que después de dos o tres semanas deberíamos ver que el kernel realiza una versión final y se abre la ventana de combinación 5.19. Correcto, ¡hay muchas posibilidades de que veamos Rust agregado al kernel de Linux en unas tres semanas!

Una vez que finalmente aterrice, espere ver un controlador simple que realmente use el soporte en la próxima versión. Entonces, si 5.19 ve el soporte de Rust, es probable que ocurra un controlador escrito en rust en 5.20. Como se mencionó anteriormente, Google es una de las partes más interesadas en el esfuerzo de Rust para Linux. Probablemente algún código relacionado con Android se adaptará a Rust, como parte del esfuerzo continuo de Google para mejorar la seguridad de su ecosistema móvil.

¿Qué podría estar mal?

Es casi seguro que Rust en Linux ocurrirá, pero ¿se garantiza que sea algo bueno? Hay una serie de posibles desventajas a considerar. Primero, la interfaz entre C y Rust es un lugar probable para que aparezcan errores imprevistos. Es código nuevo, parte de él generado automáticamente, haciendo algo nuevo, definitivamente habrá sorpresas. Eso no es realmente un problema mayor que cualquier otro código nuevo. Los errores se corrigen, los problemas se resuelven.

Lo que puede ser más problemático es la complejidad añadida de depurar problemas cuando hay que considerar otro lenguaje. Hasta ahora, el núcleo ha disfrutado de la ventaja de que todo está en C y todos los programadores que trabajan en él conocen ese lenguaje. Agregue un segundo idioma, y ​​ahora hay programadores de C, programadores de Rust y los pocos que son realmente capaces de ambos. Hay otro compilador que posiblemente podría introducir errores y otra barra de herramientas para administrar.

En última instancia, es el peligro de que simplemente no se ponga de moda. Puede ser que la comunidad central se encoja de hombros colectivamente y continúe escribiendo código en C, y Rust admita bit rots. Esto es lo menos problemático, porque el soporte de grandes jugadores como Google lo hace poco probable, e incluso si Rust muere en la vid, es fácil deshacerse del código.

¿Es probable que alguno de los problemas anteriores sea imposible de rastrear? Probablemente no. La adición de Rust cambiará ligeramente la forma en que se lleva a cabo el desarrollo del núcleo, y los cuidadores principales deberán profundizar su conocimiento de Rust. Las posibles ventajas parecen superar las desventajas. Torvalds parece haber aceptado la idea de Rust in the core, después de planchar las últimas arrugas. Esperamos ver la madurez de Rust en Linux, y les contaremos el resto de la historia después de que eso suceda.

Maya Lorenzo
Maya Lorenzo

Deja una respuesta

Tu dirección de correo electrónico no será publicada.