Rust en Linux: drivers experimentales que abren camino
Índice de contenidos
Actualizado: 2026-07-07
Rust en el kernel Linux pasó de "idea interesante" a realidad operativa durante 2022-2024. Linux 6.1 (diciembre de 2022) mergeó el soporte inicial. Linux 6.9 (mayo de 2024) trajo avances significativos: drivers experimentales mergeados, frameworks para la comunidad y los primeros casos reales de Rust en el kernel, en paralelo con un debate continuo sobre la dirección a seguir. Ya cubrimos los primeros pasos y las polémicas iniciales en nuestro análisis de esa etapa; este artículo recoge el estado real en 6.9 y lo que significa para la seguridad del sistema operativo.
Puntos clave
-
En proyectos C/C++ a gran escala como Chromium, alrededor del 70 % de los bugs de seguridad graves son de memoria; Rust los elimina en tiempo de compilación, que es el patrón que motiva su entrada en el kernel.
-
El driver GPU de Asahi Linux (Apple Silicon), escrito íntegramente en Rust, demuestra que el enfoque funciona en producción real.
-
Rust es adicional, no reemplazo de C: el consenso es "drivers nuevos pueden elegir Rust, el núcleo del kernel sigue en C".
-
La principal fricción no es técnica sino organizativa: algunos mantenedores no quieren revisar ni mantener bindings de Rust.
-
Para sistemas programmers que aprenden Rust, hay oportunidad real de contribuir ahora.
El problema que Rust aborda
Las estadísticas son consistentes en distintos proyectos C/C++ de gran escala: Chromium documenta que alrededor del 70 % de sus bugs de seguridad graves son fallos de memoria[1] (use-after-free, buffer overflows, data races), y el patrón se repite en otros codebases similares.
-
La mayoría de esos fallos son use-after-free, buffer overflows y data races: errores de gestión de memoria, no de lógica de negocio.
-
C dificulta prevenir estos bugs: la revisión de código puede detectarlos, pero no eliminarlos de forma sistemática.
-
El modelo de propiedad (ownership) de Rust hace estas clases de bugs imposibles en tiempo de compilación.
Para un kernel con decenas de millones de líneas de código y miles de contribuidores, introducir un lenguaje memory-safe es una decisión estratégica a largo plazo, no una preferencia estética.
Estado en Linux 6.9
Componentes mergeados en el árbol principal (documentados en la documentación oficial del kernel sobre Rust[2]):
-
Capa de abstracciones de Rust: bindings de las APIs del kernel (memoria, sincronización, E/S).
-
Sample drivers: ejemplos hello world y echo.
-
Infraestructura: gestión de crates, framework de testing.
Drivers experimentales en merge o en progreso:
-
Driver NVMe parcial en Rust: POC demostrativo.
-
Driver GPU de Apple Silicon (Asahi): escrito en Rust, ya en producción.
-
drivers/net/phy: algunos PHY drivers.
No hay aún módulos mainline críticos escritos únicamente en Rust. El foco sigue en la capa de abstracciones y en los drivers experimentales.
El driver Asahi: prueba de concepto exitosa
Asahi Linux[3], el proyecto de soporte de Apple Silicon en Linux, escribió su driver GPU completo en Rust. Esto es:
-
Un driver real, no un POC académico.
-
Corriendo en miles de máquinas con Apple M1/M2.
-
Con performance comparable a drivers nativos en C.
-
La demostración más convincente de que Rust en kernel funciona.
Asahi eligió Rust para un driver complejo con mucho estado (gestión de GPU, comandos, sincronización de memoria) precisamente donde C tiende a producir más bugs sutiles.
Por qué Rust frente a C en el kernel
Ventajas concretas:
-
Memory safety en compile time: use-after-free y data races son imposibles por construcción, no por disciplina.
-
Error handling explícito:
Result<T,E>en lugar de códigos de retorno que se olvidan de verificar. -
Zero-cost abstractions: mismo rendimiento que C, con más garantías.
-
Ownership claro: quién libera qué está codificado en los tipos.
-
Tooling moderno:
rustfmt,clippy, equivalente a cargo.
Desventajas en contexto kernel:
-
Curva de aprendizaje alta para desarrolladores acostumbrados a C.
-
Compile time más lento que C.
-
Ecosistema de crates diferente al subset que el kernel necesita.
-
Change churn: Rust evoluciona rápido; el kernel quiere estabilidad de API.
El debate en la comunidad
Las tensiones son reales y públicas:
A favor de Rust:
-
Linus Torvalds aprobó la inclusión, aunque con cautela.
-
Google (equipo Android), Microsoft (Azure Linux) y Red Hat están invirtiendo.
-
Nuevos drivers en algunos proyectos eligen Rust por defecto.
Con reservas:
-
Algunos mantenedores de subsistemas se niegan a revisar código Rust para sus áreas.
-
La complejidad dual (API en C + bindings de Rust) aumenta la carga de mantenimiento.
-
Los bindings de Rust se rompen con cambios internos del kernel más fácilmente que el código C.
El drama de 2024: varios mantenedores de subsistemas declararon públicamente que no van a mantener los bindings de Rust correspondientes, lo que exige que los contribuidores de Rust asuman esa responsabilidad.
Consenso provisional
La posición de la comunidad, aunque no está escrita formalmente:
-
Rust es adicional, no reemplaza a C.
-
Nuevos drivers pueden elegir Rust si el maintainer del subsistema está de acuerdo.
-
El core del kernel (scheduler, MM, FS críticos) permanece en C por ahora.
-
Evolución gradual, sin conversión big-bang.
Cómo empezar a contribuir
Para desarrolladores que quieran experimentar con Rust en el kernel:
-
Leer la documentación de Rust for Linux[4].
-
Compilar un kernel 6.1+ con soporte Rust habilitado.
-
Explorar los sample drivers en
samples/rust/del árbol del kernel. -
Escribir un driver de juguete para hardware simple.
-
Contribuir abstracciones al árbol rust-for-linux.
Si vienes de aprender el lenguaje en sí, nuestra revisión de las mejoras recientes de Rust ayuda a entender por qué cada vez más equipos lo eligen por defecto. La curva de aprendizaje es real: requiere conocer tanto Rust como el funcionamiento interno del kernel, pero es la oportunidad más concreta que el kernel ha ofrecido a nuevos contribuidores en años.
Impacto de seguridad proyectado
Si en 5-10 años la mitad del kernel nuevo estuviera en Rust:
-
Reducción de CVEs: si el kernel sigue un patrón similar al de otros proyectos C/C++ a gran escala (recordemos el ~70 % de Chromium), el potencial de reducción de fallos de memoria es considerable.
-
Cadena de suministro más robusta: drivers de terceros con garantías de seguridad más fuertes.
-
Refactorización más segura: los cambios estructurales quedan verificados por el compilador.
No resuelve bugs de lógica, concurrencia compleja ni problemas de hardware, pero es una mejora estructural significativa.
Alternativas conceptuales
Otros enfoques a la seguridad de memoria en sistemas operativos:
-
RedoxOS: sistema operativo completo escrito en Rust desde cero. Proyecto de aficionados útil como banco de pruebas.
-
Google Fuchsia: microkernel con componentes en Rust.
-
seL4: microkernel formalmente verificado en C, sin Rust.
Linux + Rust es el camino pragmático: mantiene el ecosistema masivo existente y añade seguridad de memoria de forma incremental.
Conclusión
Rust en Linux ya es realidad, no promesa. El driver de Asahi demuestra que el enfoque funciona para drivers complejos en producción. El debate sobre la velocidad de adopción continuará, y los mantenedores con reservas tienen razones legítimas sobre la complejidad añadida, pero la dirección es inequívoca. Para programadores de sistemas que aprenden Rust, hay una oportunidad real de moldear cómo evoluciona el kernel. Para las empresas que dependen de Linux, es una tendencia a seguir: la era del kernel exclusivamente en C está cerrando, lentamente pero con determinación.
Este artículo también está disponible en inglés.
Fuentes:
- Rust for Linux: documentación y quick start[4]
- Documentación oficial del kernel sobre Rust[2]
- Asahi Linux: el proyecto de soporte de Apple Silicon[3]
- Chromium: memory safety, estadísticas de bugs de seguridad graves[1]
