Rust en Linux: drivers experimentales que abren camino
Índice de contenidos
Actualizado: 2026-05-03
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-in-kernel frente al debate continuo sobre la dirección. Este artículo cubre el estado real y lo que significa para la seguridad del OS.
Puntos clave
- El 70 % de las vulnerabilidades del kernel son memory safety bugs; Rust los elimina en compile time.
- El driver GPU de Asahi Linux (Apple Silicon), escrito íntegramente en Rust, demuestra que el approach funciona en producción real.
- Rust es adicional, no reemplazo de C: el consenso es “drivers nuevos pueden elegir Rust, core kernel sigue en C”.
- La principal fricción no es técnica sino organizativa: algunos maintainers no quieren revisar ni mantener bindings 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:
- 70 % de las vulnerabilidades del kernel son memory safety bugs: use-after-free, buffer overflows, data races.
- C dificulta prevenir estos bugs: el code review puede detectarlos, pero no eliminarlos sistemáticamente.
- El ownership model de Rust hace estas clases de bugs imposibles en compile time.
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:
- Capa de abstractions Rust: bindings de APIs del kernel (memoria, sincronización, I/O).
- Sample drivers: ejemplos hello world y echo.
- Infraestructura: gestión de crates, testing framework.
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 es la capa de abstractions y drivers experimentales.
El driver Asahi: prueba de concepto exitosa
Asahi Linux[1] —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 developers 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 maintainers de subsistemas se niegan a revisar código Rust para sus áreas.
- La complejidad dual (C API + Rust bindings) aumenta la carga de mantenimiento.
- Los Rust bindings se rompen con cambios internos del kernel más fácilmente que el código C.
El drama de 2024: maintainers de algunos subsistemas declararon públicamente que no van a mantener los bindings Rust correspondientes, lo que exige que los contribuidores 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 developers que quieran experimentar con Rust en el kernel:
- Leer la documentación de Rust for Linux[2].
- Compilar un kernel 6.1+ con soporte Rust habilitado.
- Explorar los sample drivers en
samples/rust/del árbol del kernel. - Escribir un driver toy para hardware simple.
- Contribuir abstractions al árbol rust-for-linux.
La curva de aprendizaje es real —requiere conocer tanto Rust como las internals del kernel— pero es la oportunidad más concreta que el kernel ha ofrecido a nuevos contributors 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: los memory safety bugs representan el 60-70 % de los CVEs del kernel. El potencial de reducción es masivo.
- Supply chain más robusta: drivers de terceros con garantías de seguridad más fuertes.
- Refactoring más seguro: los cambios estructurales son 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 memory safety en sistemas operativos:
- RedoxOS: OS completo escrito en Rust desde cero. Hobby project útil como playground.
- 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 safety de forma incremental.
Conclusión
Rust en Linux ya es realidad, no promesa. El driver de Asahi demuestra que el approach funciona para drivers complejos en producción. El debate sobre la velocidad de adopción continuará —los maintainers con reservas tienen razones legítimas sobre la complejidad añadida— pero la dirección es inequívoca. Para systems programmers que aprenden Rust, hay oportunidad real de moldear cómo evoluciona el kernel. Para empresas que dependen de Linux, es una tendencia a seguir: la era del kernel exclusivamente en C está cerrando, lentamente pero con determinación.
