Rust en el kernel de Linux: primeros pasos y polémicas

Actualizado: 2026-05-03

Desde la versión 6.1 (diciembre de 2022), el kernel de Linux acepta oficialmente código en Rust. En 2023 hemos visto los primeros drivers reales en upstream y el debate dentro de la comunidad sobre cómo integrar dos lenguajes con filosofías muy distintas. Cubrimos en qué punto estamos, qué módulos lo usan ya, y por qué algunos veteranos del kernel lo ven con escepticismo.

Puntos clave

• Rust entra al kernel para eliminar una clase de bugs imposible de erradicar con C: errores de seguridad de memoria en drivers nuevos.
• La estrategia es conservadora: código C existente no se reescribe; Rust se usa para módulos y drivers nuevos.
• El driver de GPU Apple AGX para Asahi Linux es el ejemplo real más destacado hasta la fecha.
• La polémica social — dos culturas de desarrollo en el mismo proyecto — es el obstáculo mayor, no el técnico.
• La infraestructura C/Rust requiere bindgen para los bindings y un compilador rustc exacto por release del kernel.

El “por qué” del proyecto

El kernel de Linux acumula 30+ años de C, con todo lo bueno y lo malo: rendimiento extraordinario, control total sobre memoria y hardware, pero también una buena parte de los CVE críticos del sistema operativo causados por errores de seguridad de memoria — use-after-free, buffer overflows, data races. Microsoft estimó en 2019 que ~70% de sus vulnerabilidades anuales eran de este tipo. Las cifras en el kernel de Linux son comparables.

Rust ofrece, sin GC, garantías de seguridad de memoria verificadas en compilación. La idea central: si los nuevos drivers — sobre todo aquellos escritos por personas con menos años de C en el cuerpo — se escriben en Rust, una clase entera de bugs desaparece. El kernel C antiguo no se reescribe; solo se evita añadir más superficie de ataque con el estilo viejo.

Estado en 2023: qué hay en upstream

Lo que ya está en upstream o cerca de estarlo:

• Infraestructura base: bindings de Rust a estructuras core del kernel (sk_buff, file_operations, ioctl, etc.) y el “abi” de cómo Rust llama a C y viceversa.
• Driver Apple AGX (Asahi Linux): GPU de Apple Silicon, escrito en Rust por Asahi Lina. Mantiene Linux usable en Macs M1/M2.
• Driver NVMe inicial y experimentos de drivers de red en revisión.
• PHY de Ethernet (algunos modelos).
• Filesystem PuzzleFS: experimental, pero ejemplo de subsistema completo en Rust.

Es un comienzo modesto comparado con la inmensidad del kernel, pero la inversión de Google, Microsoft, Asahi y otros mantenedores garantiza continuidad.

Cómo funciona la convivencia C/Rust

El código Rust del kernel se compila a un blob estático que el linker integra como cualquier otro objeto. Las llamadas entre lenguajes pasan por capas de bindings generadas por bindgen, que transforman headers de C en tipos de Rust.

Restricciones importantes a conocer:

• Sin std: el kernel no tiene libc ni allocator estándar. Se usa una variante mínima (alloc + tipos kernel-específicos).
• unsafe abundante en bindings: la frontera entre lenguajes requiere romper algunas garantías de Rust. La idea es contener unsafe en módulos pequeños y bien revisados.
• Compilador específico por release: el kernel exige una versión exacta de rustc por release, sin tolerancia a versiones menores. Esto choca con el modelo de Rust de “siempre al día”.

El resultado es Rust, pero más restringido que en userspace. Las abstracciones todavía maduran release a release.

La polémica social

Dos comunidades, dos culturas. La polémica visible más sonada del año: en 2023, algunos mantenedores de C consideraron las expectativas de los desarrolladores Rust como demanda de cambio de cultura — pedir documentación más estricta de invariantes en interfaces que llevaban décadas funcionando “porque sí”. Esto terminó con dimisiones y discusiones agrias en la lista de correo del kernel.

Linus Torvalds ha dado apoyo público al proyecto pero también ha pedido paciencia de ambos lados.

Los argumentos en contra más razonables (no los puramente reaccionarios):

• Coste cognitivo dual. Mantenedores que revisan código en C y Rust necesitan competencia en ambos lenguajes.
• Toolchain más pesada. Construir el kernel ahora requiere rustc además de gcc/clang.
• Debug más complejo. Las herramientas tradicionales (kgdb, ftrace) están diseñadas para C; el soporte para Rust va detrás.
• Mantenibilidad a 20 años. El kernel debe seguir compilable décadas. Apostar por un lenguaje relativamente joven asume un riesgo de longevidad.

Los argumentos a favor son los obvios: clases enteras de bugs eliminados de antemano, mejor onboarding para desarrolladores nuevos, modelo de tipos más expresivo. Comparado con lo que vemos en tecnologías adyacentes como WebAssembly — donde Rust también tiene un rol central —, la tendencia de adopción es clara.

Qué esperar a corto plazo

Pronósticos razonables para los próximos 12-18 meses:

• Más drivers de hardware nuevo escritos directamente en Rust, especialmente donde haya grandes empresas detrás (GPUs, NICs).
• Subsystems experimentales (filesystems, network stacks) con implementaciones Rust paralelas a las de C.
• Sin reescritura de partes core (scheduler, MM, VFS) — el coste y riesgo son demasiado altos.
• Continuación del debate cultural, con mejoras graduales en la documentación de interfaces.

Conclusión

Rust en el kernel de Linux es ya una realidad técnica, no un experimento académico. Los próximos años decidirán si el experimento escala — si la comunidad encuentra una forma de integrar dos culturas y dos lenguajes sin colapsar bajo el peso del cambio. La apuesta tiene sentido a largo plazo para reducir la superficie de bugs de memoria en drivers nuevos, pero el camino es más social que técnico.

Si te interesa contribuir, Rust for Linux^[1] es el punto de entrada.

1. Rust for Linux