Rust en Linux: drivers estables y primeras contribuciones serias

Actualizado: 2026-05-03

Cuando Linus Torvalds fusionó las primeras piezas de soporte para Rust en Linux 6.1 en octubre de 2022, la advertencia fue explícita: era un experimento. Tres años después tenemos suficiente material para juzgar sin especular. Los drivers en Rust han empezado a marcarse como estables, la API interna ha madurado y algunos subsistemas estratégicos han elegido Rust como lenguaje preferido para código nuevo. El proyecto ha salido ya de la fase puramente exploratoria.

Puntos clave

• El driver Apple ASAHI para GPU de Apple Silicon es el caso más sonado: grande, activo y crítico para un público concreto.
• El módulo binder de Android reescrito en Rust está en fusiones sucesivas y se perfila como mecanismo de IPC a medio plazo.
• El código Rust en árbol sigue por debajo del 1 % del kernel, pero el crecimiento en los últimos seis meses ha sido más rápido que en cualquier ventana anterior.
• Al menos dos mantenedores veteranos se han retirado citando la presión por aceptar Rust como factor.
• Google ha demostrado caídas paralelas en CVE de memory safety a medida que Android incorpora más código Rust.

Qué hay estable en árbol

En Linux 6.14 conviven varios drivers Rust fusionados y marcados como funcionales:

• Driver Apple ASAHI para la GPU de Apple Silicon: el único camino práctico para aceleración gráfica en portátiles ARM de Apple corriendo Linux. Es grande, activo y crítico para un público concreto, y ha sido la prueba de estrés del soporte Rust en términos de calidad.
• Módulo binder para Android, reescrito en Rust, con fusiones sucesivas en las últimas versiones.
• Partes del subsistema nvme con implementaciones parciales en Rust en revisión activa, con expectativa de fusión en 6.15 o 6.16.
• Soporte null-block (usado en benchmarking y testing) completamente reescrito.

El tamaño del código Rust en árbol sigue siendo pequeño en términos relativos, probablemente por debajo del 1 % del total. Pero el crecimiento en los últimos seis meses ha sido más rápido que en cualquier ventana anterior, y la cadencia de parches enviados por la lista rust-for-linux se ha multiplicado.

La madurez de la API interna

Uno de los problemas más grandes del inicio fue que Rust en el kernel necesitaba mapear tipos y comportamientos del C subyacente, y ese mapeo no estaba claro. Un conjunto de patrones consolidados ya permite escribir drivers sin reinventar la rueda cada vez:

• Abstracciones para locks, buffers de DMA, listas enlazadas estilo kernel y gestión de errores siguen una forma idiomática ajustada a las restricciones del kernel.
• No se usa el runtime estándar de Rust, no hay alloc del standard library y el manejo de memoria es explícito.
• La capa de build se ha estabilizado: compilar el kernel con soporte Rust ya no requiere magia.

Aprender a escribir Rust kernel tiene una curva propia distinta a Rust en userspace, pero la curva es cada vez más corta porque los ejemplos buenos en árbol son más. Quien ya trabaja con herramientas de profiling del sistema operativo como eBPF tiene una base útil para entender el modelo de ejecución del kernel.

La polémica interna que no se ha cerrado

No todo el mundo está cómodo con la dirección. A lo largo de 2024 hubo al menos dos salidas públicas de mantenedores veteranos citando la presión por aceptar Rust en sus subsistemas como razón para retirarse. La discusión sobre si Rust debe ser solo lenguaje permitido o lenguaje preferido en nuevas contribuciones sigue abierta.

La posición de Torvalds ha sido consistente: Rust puede convivir con C si los puentes están bien diseñados, y los mantenedores tienen la última palabra en sus árboles. No obliga a nadie a aceptar código Rust, pero tampoco lo bloqueará por principio cuando la calidad es buena.

El debate técnico de fondo es legítimo. Rust añade carga cognitiva para los mantenedores C que revisan código Rust, y añade complejidad al sistema de build. A cambio ofrece seguridad de memoria y un modelo de concurrencia más claro. El equilibrio depende del subsistema: para drivers nuevos con poco código legado, la ganancia es evidente; para código maduro con décadas de C pulido, la ganancia es menos clara.

Adopción fuera del árbol principal

Quien está acelerando más el uso de Rust en kernel no es Linux mainline sino Android. Google ha invertido de forma pública y sostenida en Rust para Android desde 2021, y las estadísticas de vulnerabilidades que publican son el mejor argumento por demostración del enfoque. Cada nueva versión de Android tiene más líneas Rust, y los CVE de memory safety caen en paralelo.

Algunos kernel forks comerciales como los de Red Hat, Oracle y SUSE están siguiendo de cerca. No se observa todavía código Rust desplegado masivamente en servidores enterprise, pero es esperable dado el ritmo conservador de los kernels enterprise.

También existen proyectos experimentales: Maestro (un kernel completamente escrito en Rust), Asterinas, e investigadores académicos trabajando en hipervisores Rust. Ninguno va a reemplazar Linux, pero todos aportan ideas que eventualmente filtran a rust-for-linux. Algunos de estos hipervisores Rust compiten conceptualmente con Firecracker en el espacio de microVMs.

Lo que sigue sin resolver

Tres piezas importantes permanecen abiertas:

1. Integración con herramientas de análisis estático que Linux usa para validar código C, como sparse o Coccinelle. Adaptarlas a Rust es no trivial.
2. Soporte multiarquitectura. Rust compila bien para x86_64 y arm64, que cubren la mayoría de despliegues, pero PowerPC, RISC-V y varias arquitecturas embebidas tienen soporte Rust parcial o experimental.
3. Formación. Hay pocos desarrolladores con experiencia simultánea en Rust y kernel Linux. Sin una base de contribuyentes ancha, el riesgo es que Rust en Linux dependa de unos pocos nombres clave.

Mi lectura

El experimento ha dejado de ser experimento. Rust en el kernel Linux es una tecnología de producción con drivers reales, cadencia de fusiones sostenida y adopción aguas abajo en proyectos como Android donde las métricas de seguridad son medibles. No está dominando el kernel ni lo hará en los próximos años, pero tampoco es una curiosidad.

Lo que me parece notable es cómo está forzando debates que el ecosistema C podía posponer indefinidamente: ownership explícito, modelos de concurrencia formalizados, garantías de seguridad verificables por el compilador. Estos debates benefician incluso a las partes del código que siguen siendo C puro.

A quien valora Rust como lenguaje, este es un buen momento para explorar rust-for-linux. Los documentos son claros, hay issues etiquetados para iniciarse y el proyecto necesita manos. La dirección lleva tres años siendo consistente, y los datos de seguridad apoyan la tesis de origen.