El lenguaje de programación Rust siempre ha tenido como objetivo reemplazar a C en el desarrollo del kernel de Linux y es que a medida que Rust ha madurado, varios desarrolladores han expresado un interés creciente en su uso en el kernel de Linux.

En la Conferencia Virtual de Linux Plumbers 2020, el flujo de microconferencias de LLVM organizó una sesión sobre preguntas abiertas y barreras para la aceptación ascendente de Rust en el kernel de Linux.

El interés en este tema es visible, ya que esta sesión fue la más concurrida del evento de 2020.

Entonces, ¿deberíamos ahora reescribir todo el kernel de Linux con el lenguaje Rust? Esta discusión no data de hoy y se ha acentuado desde la aparición de la primera versión estable de Rust en 2015.

En vista de las posibilidades que ofrece Rust, algunos sugieren hacerlo. Este año, en la conferencia Linux Plumbers en agosto, los oradores tuvieron tiempo de nuevo para discutirlo.

Y lo sorprendente es que parecen estar de acuerdo unánimemente, no en reescribir el código existente en Rust, sino en que el desarrollo del kernel continúe usando Rust. Es decir, visualizan un mundo en el que se podrían escribir nuevas piezas de código en Rust.

Esta sesión se basó en el trabajo anterior de muchos desarrolladores, incluida una charla que dieron el año pasado Alex Gaynor y Geoffrey Thomas en la Linux Security Summit.

En la conferencia, presentaron su trabajo sobre la creación de prototipos de los módulos del kernel de Rust y abogaron por la adopción de Rust en el kernel.

Citaron trabajos que muestran que aproximadamente dos tercios de las vulnerabilidades del kernel a las que se les han asignado CVE en Android y Ubuntu están relacionadas con problemas de seguridad de la memoria.

Terminaron explicando que Rust puede evitar completamente esta clase de error gracias a API más seguras habilitadas por su tipo de sistema y su verificador de préstamos.

Este estudio logró convencer a varios mantenedores y a Linus Torvalds, quien apoyó la introducción de Rust en el kernel. Thomas y Gaynor, Josh Triplett, codirector del equipo de lenguaje de Rust y desarrollador del kernel de Linux desde hace mucho tiempo, así como otros desarrolladores interesados, participaron en la discusión sobre el tema.

Tocaron brevemente su trabajo hasta ahora y algunos de sus primeros pensamientos y preguntas antes de abrir la mayor parte del tiempo para la discusión.

Estos son el uso de las API existentes en el kernel, el soporte de la arquitectura y una pregunta sobre la compatibilidad ABI entre Rust y C.

De hecho, inicialmente creen que la introducción de Rust en la estructura de árbol debe respetar las API existentes C. 

Sin embargo, todos sienten que el diablo está en los detalles, y tanto el trabajo realizado hasta ahora como la conversación durante la sesión han revelado algunos desafíos abiertos.

Por ejemplo, Linux hace un uso intensivo de macros de preprocesador y funciones en línea, que no son tan fácilmente compatibles con la herramienta bindgen y la interfaz de funciones externas de Rust.

Según ellos, actualmente la única implementación madura de Rust es el compilador rustc, que emite código a través de LLVM.

El kernel de Linux admite una amplia variedad de arquitecturas, muchas de las cuales no tienen disponible un backend LLVM.

Por su parte, Triplett sugirió que agregar Rust al kernel ayudaría a incrementar el soporte arquitectónico para Rust, citando su experiencia con el proyecto Debian. Mencionó que la introducción del software Rust en Debian ha ayudado a motivar a los entusiastas y usuarios de arquitecturas de nicho para mejorar el soporte de Rust, y espera agregar soporte de kernel para tener un efecto similar.

En particular, estaba convencido de que cualquier arquitectura con un backend LLVM sería rápidamente compatible con Rust. La discusión también se centró en las implementaciones alternativas de Rust como un camino hacia un soporte de arquitectura más amplio.

La sesión terminó sin más hitos específicos, pero parece que, en general, hay entusiasmo por apoyar a Rust Mods y un creciente acuerdo sobre los requisitos generales para este soporte.