En 2021, Miguel Ojeda presentó el proyecto Rust-for-Linux con una propuesta concreta: añadir soporte oficial de Rust al árbol del kernel para que los desarrolladores pudieran escribir módulos y drivers en ese lenguaje. No era una idea nueva, pero era la primera con tracción real. Ojeda llevaba tiempo trabajando en las abstracciones necesarias y consiguió que la comunidad lo tomara en serio.
Linus Torvalds aprobó la integración inicial en Linux 6.1, publicado en diciembre de 2022. Lo que entró entonces no eran drivers en producción, sino la infraestructura: el directorio rust/ en el árbol del kernel, las herramientas de compilación y las abstracciones básicas para definir módulos. El mensaje era claro: Rust tiene un hueco aquí, aunque sea pequeño por ahora.
La motivación detrás de todo esto no es caprichosa. Alrededor del 70% de las vulnerabilidades de seguridad en software de sistemas son errores de memoria: use-after-free, desbordamientos de buffer, punteros nulos sin verificar. Rust previene la mayoría de esos errores en tiempo de compilación, antes de que el código llegue a producción. En un kernel con más de 30 millones de líneas de C acumulando décadas de complejidad, eso tiene peso.
Lo que no cambia: Rust no reemplaza a C en el kernel. Coexisten. Los componentes existentes siguen en C y nadie va a reescribirlos. La idea es que los drivers y módulos nuevos puedan escribirse en Rust si el autor así lo decide.
Qué entró en cada versión del kernel
El proceso ha sido gradual. Cada versión del kernel ha añadido algo concreto:
- Linux 6.1 (diciembre 2022): soporte básico de Rust, directorio
rust/en el árbol oficial, abstracciones para módulos. La base sobre la que construir. - Linux 6.8 (2024): primer driver de red en Rust para hardware de NovaStar Tech integrado en el árbol oficial. Un hito real: código de producción en Rust dentro del kernel.
- Linux 6.11 (septiembre 2024): primeras abstracciones de almacenamiento en bloque en Rust, lo que abre la puerta a drivers de disco escritos en el lenguaje.
- Linux 6.12 (noviembre 2024): abstracciones para dispositivos PCI y platform devices. Esto es la base para drivers de hardware físico de verdad.
- 2026: hay ya varios drivers reales en Rust integrados en el árbol, incluido trabajo notable para la GPU de Apple (el proyecto Asahi, conducido por Lina Asahi).
La progresión es lenta pero constante. Cada versión amplía un poco más las abstracciones disponibles, lo que a su vez permite que más tipos de drivers puedan escribirse en Rust.
Cómo funciona un módulo de kernel en Rust
El kernel de Linux tiene su propia manera de registrar módulos y drivers, originalmente pensada para C. Para Rust, se han creado abstracciones que envuelven esas estructuras C internas y las exponen con la API propia de Rust.
Un driver en Rust implementa traits como Driver o FileOpener, según qué tipo de dispositivo gestiona. El equivalente a module_init en C es la macro module!, que registra el módulo con el kernel al cargarlo. El resultado es parecido a esto:
use kernel::prelude::*;
module! {
type: MiDriver,
name: "mi_driver",
author: "Desarrollador",
description: "Driver de ejemplo en Rust",
license: "GPL",
}
struct MiDriver;
impl kernel::Module for MiDriver {
fn init(_module: &'static ThisModule) -> Result<Self> {
pr_info!("Driver cargadon");
Ok(MiDriver)
}
}
El compilador de Rust hace aquí algo que C no puede: garantiza en tiempo de compilación que no hay punteros nulos sin verificar, que no hay uso de memoria después de liberarla y que no hay carreras de datos entre threads del kernel. No porque el programador sea más cuidadoso, sino porque el lenguaje no compila si alguna de esas condiciones se da.
La parte que sigue siendo C
El scheduler, la gestión de memoria virtual, los sistemas de ficheros, las pilas de red, el soporte de arquitecturas, la gestión de energía, y un largo etcétera: todo eso sigue en C y va a seguir así durante años. Las abstracciones Rust del kernel son bindings sobre el código C existente, no reimplementaciones.
Eso significa que para escribir un driver en Rust tienes que entender tanto Rust como las estructuras internas del kernel que estás envolviendo. No es que el nivel de exigencia baje: sube, porque tienes dos capas que conocer bien.
El objetivo declarado del proyecto no es convertir el kernel a Rust. Es hacer que los componentes nuevos puedan escribirse en Rust cuando tenga sentido, sobre todo en sitios donde los errores de memoria tienen consecuencias graves.
El debate interno: escépticos y defensores
La integración de Rust no fue recibida con unanimidad. Christoph Hellwig, mantenedor con mucho peso en el subsistema de almacenamiento, se mostró crítico con la dirección del proyecto. Su argumento principal: el kernel ya tiene sus propias convenciones de seguridad, los compiladores de Rust son más lentos que GCC para compilar el kernel completo y añadir un segundo lenguaje aumenta la complejidad de mantenimiento.
El argumento contrario es más simple: prevenir categorías enteras de bugs en compile time tiene valor objetivo. Si el 70% de los CVEs relacionados con el kernel implican errores de memoria, un lenguaje que los elimina por diseño ayuda aunque la adopción sea parcial.
En 2026, el debate ha quedado bastante zanjado en la práctica. Linus Torvalds ha confirmado en varias ocasiones su apoyo a Rust-for-Linux y el proyecto sigue activo con más contribuidores y más abstracciones en cada versión. Los escépticos no han desaparecido, pero el tren no ha parado.
Qué significa para los desarrolladores de drivers
Por ahora, la elección es tuya: puedes escribir un driver nuevo en C o en Rust. El kernel acepta ambos. Para escribirlo en Rust necesitas que rustc y bindgen estén disponibles en el entorno de compilación del kernel, algo que se configura con las opciones habituales de make menuconfig.
La documentación oficial está en el propio árbol del kernel, bajo Documentation/rust/. No está mal para lo reciente que es el soporte. Hay guías de inicio, referencia de abstracciones disponibles y ejemplos de módulos simples.
Lo que no debes esperar es que escribir un driver en Rust sea fácil si no conoces el kernel. Las abstracciones de Rust te protegen contra errores de memoria, pero no te explican cómo funciona un bus PCI, cómo gestiona el kernel las interrupciones o cuándo usar kmalloc frente a vmalloc. Eso lo tienes que saber tú.
Si te interesa empezar, el proyecto Rust-for-Linux mantiene ejemplos en su repositorio y hay drivers de muestra en samples/rust/ dentro del árbol del kernel. Son buenos puntos de partida para entender la API antes de meterte con hardware real.
Para ampliar contexto sobre dónde encaja Rust más allá del kernel, puedes ver Rust en sistemas y el kernel Linux. Y si te planteas cuándo elegir Rust frente a otros lenguajes de alto rendimiento, Go vs Rust: seguridad de memoria comparada repasa las diferencias concretas.
Rust en Android: el mismo camino, distinta escala
Google tomó una decisión parecida para Android en 2021: adoptar Rust en AOSP (Android Open Source Project) para el código nuevo de los componentes más sensibles. La diferencia es la escala y la velocidad: Android tiene un ciclo de actualización más controlado que el kernel upstream y Google pudo empujar Rust de forma más agresiva.
En 2026, millones de líneas de código nuevo en Android están escritas en Rust. Los componentes afectados incluyen la pila de Bluetooth, partes del subsistema de medios y código de red. Los resultados medibles son positivos: en las áreas donde se adoptó Rust, las vulnerabilidades relacionadas con errores de memoria han bajado de forma notable. Google ha publicado datos internos al respecto en varias conferencias de seguridad.
El caso de Android es útil porque lleva más tiempo en producción que el soporte en el kernel upstream y ya tiene resultados concretos que medir, no solo promesas.
El panorama en 2026: ¿ha funcionado?
Depende de lo que esperaras. Si esperabas que Rust transformara el kernel en dos o tres años, la respuesta es no. Si esperabas un proceso gradual con adopción real pero limitada, la respuesta es sí.
Rust-for-Linux sigue activo, con más contribuidores que en 2022 y con abstracciones nuevas en casi cada versión del kernel. Hay drivers reales en el árbol principal, no solo experimentos. El soporte no ha sido revertido ni abandonado.
El consenso técnico entre quienes trabajan en el proyecto es que escribir código de kernel en Rust elimina categorías enteras de bugs que en C requieren mucha disciplina y revisión para evitar. El coste es la curva de aprendizaje: aprender Rust bien lleva tiempo, y aprender las abstracciones del kernel lleva más. Nadie dice que sea fácil. Pero los que han pasado por eso suelen decir que merece la pena.
Imagen: Pexels / Kevin Ku