Desventajas y retos de usar Rust en el kernel Linux

La llegada de Rust al núcleo de Linux ha sido cualquier cosa menos tranquila. Durante meses la comunidad del kernel ha vivido una auténtica tormenta, con discusiones públicas, renuncias sonadas y acusaciones de boicot que recordaban más a una serie dramática que a un proyecto de software libre. Lo que empezó como un “experimento” para introducir un lenguaje seguro en memoria dentro del corazón de Linux ha terminado abriendo una brecha profunda entre quienes defendían el monolingüismo en C y quienes veían imprescindible dar el salto a un lenguaje más moderno.

Hoy el panorama es muy diferente: Rust ha dejado oficialmente de ser experimental y ya se considera parte nuclear del kernel. Sin embargo, que se haya ganado esa batalla no significa que todo sean ventajas. La integración de Rust en Linux 6.x ha destapado desafíos técnicos, tensiones políticas dentro del proyecto y dudas sobre su impacto a largo plazo, especialmente en aspectos como la estabilidad, la compatibilidad y la forma tradicional de trabajar en el desarrollo del kernel.

De experimento polémico a lenguaje oficial del kernel

El punto de inflexión llegó en la Maintainers Summit, la cumbre anual en la que los principales responsables del kernel se reúnen para decidir el rumbo técnico del proyecto. Allí, tras meses de debate muy enconado, se acordó retirar la etiqueta de “experimental” a Rust dentro del árbol principal de Linux, convirtiéndolo en un lenguaje de primera clase junto a C. Esta decisión cierra la puerta, al menos a corto y medio plazo, a quienes exigían expulsar Rust y mantener el kernel exclusivamente en C.

Los primeros pasos para soportar Rust en el núcleo comenzaron hace unos tres años. Desde entonces, se han ido integrando pequeños bloques de código, sobre todo en forma de nuevos drivers y componentes relativamente aislados. Durante ese tiempo, la etiqueta de “experimental” servía como especie de red de seguridad: permitía probar Rust sin asumir completamente el compromiso de mantenerlo de forma indefinida, algo que varios desarrolladores veteranos defendían como prudente.

La comunidad, sin embargo, se dividió en dos bandos claramente enfrentados: por un lado, quienes veían Rust como una amenaza a la estabilidad, a la coherencia del código y a la filosofía conservadora del kernel; por otro, quienes insistían en que el futuro de la seguridad pasaba por abandonar el uso exclusivo de lenguajes inseguros en memoria como C y C++. Esta fractura llegó a un nivel tan personal que algunos implicados describieron el clima como “casi religioso”.

Linus Torvalds, tradicionalmente prudente con los cambios radicales, mostró al principio cierto escepticismo, sobre todo respecto a las promesas de seguridad de Rust y a los posibles impactos en el rendimiento. No obstante, terminó dando luz verde a la integración bajo una serie de reglas y limitaciones, con la idea de ir comprobando en la práctica hasta dónde se podía llegar sin comprometer el comportamiento del kernel.

Un conflicto interno con dimisiones, desgaste y acusaciones de sabotaje

La polémica por Rust en el kernel no se quedó en un desacuerdo técnico educado. Varias figuras relevantes del proyecto, especialmente del lado pro-Rust, terminaron quemadas por lo que describieron como una guerra constante contra críticas que no tenían que ver con el código en sí, sino con posiciones ideológicas o inercia histórica del proyecto.

Miguel Ojeda, ingeniero español y principal impulsor de Rust for Linux, ha sido la cara más visible de este esfuerzo. Desde el arranque del proyecto, se encargó de liderar la integración, coordinar parches y debatir propuestas con el resto de mantenedores. A día de hoy, es el único mantenedor formal de Rust for Linux, apoyado por revisores, después de que otros colaboradores clave decidieran apartarse por agotamiento y frustración.

Wedson Almeida Filho, ingeniero de Microsoft y uno de los grandes defensores de Rust en el kernel, acabó renunciando a su puesto dentro del proyecto en 2023. En su mensaje de despedida en la lista de correo del kernel, explicó que, tras casi cuatro años implicado, ya no tenía la energía ni las ganas para seguir lidiando con lo que calificó como “ruido no técnico” y “tonterías” ajenas a los méritos del código. Prefería dejar el testigo a otras personas que todavía conservaran entusiasmo para seguir peleando.

Su marcha puso de relieve lo tóxico que se había vuelto el ambiente para parte del bando pro-Rust. Wedson insistió en que los kernels del futuro deberán escribirse, en gran parte, en lenguajes seguros en memoria, y alertó de que, si Linux no hace esa transición, otro kernel podría acabar desplazándolo de la misma forma que Linux desplazó en su día a Unix en muchos ámbitos.

A la carga emocional de las renuncias se sumó un episodio todavía más delicado: las acusaciones de sabotaje interno. Desarrolladores como Hector Martin (conocido por su trabajo en Asahi Linux, el proyecto que porta Linux a los chips de Apple) señalaron públicamente a algunos mantenedores veteranos, como Christoph Hellwig, de actuar deliberadamente para frenar la integración de Rust. Se habló de rechazar parches críticos, de poner trabas constantes y de intentar que el esfuerzo muriera por agotamiento.

Hellwig llegó a calificar la iniciativa de Rust en el kernel como un “cáncer”, una expresión que encendió aún más los ánimos y simbolizó la polarización existente. Para unos, Rust era una intromisión innecesaria en un ecosistema que, con todas sus carencias, lleva décadas funcionando; para otros, esa resistencia equivalía a negar una evolución que consideran imprescindible para reforzar la seguridad de un componente tan crítico como el kernel.

Por qué Rust ha ganado: memoria segura, modernidad y atractivo para nuevos desarrolladores

A pesar del ruido, Rust ha terminado imponiéndose por sus características técnicas. Su principal baza es la seguridad de memoria integrada en el propio diseño del lenguaje: el sistema de préstamos, el control de propiedad y el compilador rígido hacen extremadamente difícil introducir desbordamientos de búfer, dobles liberaciones de memoria o accesos a punteros colgantes, todos ellos clásicos en C.

Datos presentados en conferencias como la Linux Security Summit de 2019 refuerzan este argumento: análisis realizados por desarrolladores como Alex Gaynor y Geoffrey Thomas indicaban que casi dos tercios de las vulnerabilidades de seguridad de Linux proceden de errores de gestión de memoria, originados en debilidades intrínsecas de C y C++. La promesa de Rust es reducir drásticamente ese tipo de fallos, al obligar a seguir patrones de acceso más seguros desde la propia API y en tiempo de compilación.

Wedson Almeida Filho resumió muy bien la posición a favor de Rust al afirmar que el lenguaje ya está listo para compartir protagonismo con C en el desarrollo del kernel, ayudando a disminuir la cantidad de bugs y fallos de seguridad en código privilegiado sin renunciar al rendimiento. La idea no es reescribir todo Linux, sino incorporar nuevas partes críticas en Rust para disminuir la superficie de ataque futura.

Además de la seguridad, Rust aporta un atractivo estratégico para el ecosistema Linux. Muchas empresas tecnológicas lo ven como un lenguaje moderno, productivo y más amigable para parte de los desarrolladores jóvenes. Integrarlo en el kernel convierte a Linux en un proyecto más interesante para quienes ya programan en Rust o quieren aprenderlo en un contexto de alto impacto, y eso puede ayudar a renovar la base de contribuyentes con perfiles más diversos. Para entender mejor la relevancia del proyecto dentro del panorama, consulta más en el ecosistema Linux.

Compañías como Cisco, Samsung o Canonical han manifestado un apoyo explícito a la maduración de Rust en el kernel. Para estos actores, la posibilidad de combinar el rendimiento y la proximidad al hardware de C con las garantías de Rust abre una vía atractiva para construir drivers y subsistemas menos propensos a errores catastróficos, sin tener que abandonar Linux como plataforma principal.

Las desventajas técnicas de Rust en el kernel Linux

Que Rust prometa más seguridad no significa que su adopción en el kernel esté libre de inconvenientes. De hecho, gran parte de la resistencia interna proviene de preocupaciones técnicas legítimas y de la forma en que Rust interactúa con un código base gigante, mayoritariamente escrito en C, con casi tres décadas y media de historia y decenas de millones de líneas.

Uno de los puntos más delicados es la dependencia de las últimas versiones del compilador de Rust. El proyecto Rust evoluciona rápido, con una cadencia de versiones agresiva y funcionalidades que, a menudo, empiezan siendo inestables (“nightly”) antes de consolidarse. La integración en el kernel está obligando a muchos desarrolladores a seguir muy de cerca la versión actual del compilador, algo que choca con la filosofía tradicional de Linux, que prefiere apoyarse en herramientas extremadamente maduras y conservadoras.

Esta necesidad de ir casi al día con el compilador genera temores en torno a la estabilidad y la retrocompatibilidad. Algunos miembros del equipo del kernel temen que se terminen usando características del lenguaje o de la biblioteca estándar cuya presencia futura no esté totalmente garantizada, lo cual podría comprometer la mantenibilidad a largo plazo. En un proyecto cuyo código puede vivir décadas, apoyar partes críticas en elementos potencialmente cambiantes es visto, como mínimo, con recelo.

Otro foco de conflicto es la petición de llevar el soporte de Rust a versiones LTS del kernel. Muchas empresas dependen de ramas de soporte extendido y son extremadamente cautas con la introducción de nuevas tecnologías en sus bases de código. La política del kernel suele evitar los “backports” masivos de nuevas funcionalidades, y Rust no es una excepción. Sin embargo, algunas voces presionan para que ese soporte llegue también a estas versiones, lo que añade más complejidad organizativa y técnica.

En el plano puramente técnico dentro del kernel, también han surgido retos específicos. Uno de los más mencionados está relacionado con los deadlocks o bloqueos mutuos: situaciones en las que dos o más procesos se quedan esperando unos por otros y el sistema no progresa. Mientras que Rust puede considerar ciertos patrones seguros desde el punto de vista del lenguaje (sin comportamiento indefinido), eso no implica que sean aceptables dentro del contexto de sincronización del kernel Linux, lo que obliga a revisar con lupa cómo se diseñan las primitivas y las abstracciones de concurrencia.

Choque con las reglas del desarrollo del kernel: drivers duplicados y abstracciones incompletas

La integración de Rust también ha tensado algunas normas no escritas —y otras muy escritas— del proyecto. Una de las reglas tradicionales del desarrollo del kernel es evitar los controladores duplicados que hagan esencialmente lo mismo, salvo casos excepcionales muy justificados. Esta política busca minimizar el mantenimiento redundante y reducir la confusión de los usuarios y distribuidores.

Sin embargo, varios desarrolladores interesados en experimentar con Rust han mostrado disposición a violar parcialmente esa regla. Su idea es implementar nuevos drivers en Rust, aun cuando ya existan equivalentes maduros en C, con el objetivo de probar patrones, medir rendimiento, validar abstracciones y detectar posibles problemas de integración. Este enfoque experimental implica convivir con casos en los que hay dos drivers distintos para el mismo hardware o funcionalidad, algo que muchos mantenedores consideran poco deseable.

Parte de esta tensión viene de que la capa de abstracción necesaria para escribir drivers en Rust todavía no está completamente definida. Faltan APIs estables y bien documentadas que permitan a los desarrolladores trabajar con Rust de forma tan directa y controlada como llevan décadas haciéndolo con C. Hasta que esas abstracciones maduren, es probable que se sigan necesitando excepciones o soluciones ad hoc, algo que choca con la disciplina habitual del proyecto.

Esta situación ha llevado al equipo de Rust for Linux, liderado por Miguel Ojeda, a solicitar excepciones explícitas a las reglas de no duplicación de controladores. Aunque se entiende la motivación —explorar las capacidades del lenguaje en un entorno real—, cada excepción de este tipo añade presión al proceso de revisión del kernel y al esfuerzo de mantenimiento a largo plazo, precisamente uno de los puntos que más preocupan a sus críticos.

El resultado es un equilibrio inestable entre innovación y conservadurismo: por un lado, hay un deseo evidente de aprovechar Rust para probar nuevas ideas y mejorar la seguridad; por otro, está el temor a erosionar principios que han permitido que el kernel siga siendo manejable pese a su tamaño y complejidad actuales.

Cadena de herramientas y dependencia tecnológica adicional

Otro conjunto de desventajas viene de la complejidad extra en la cadena de herramientas. El kernel siempre ha tenido una dependencia muy fuerte de GCC, pero con el tiempo se ha ido abriendo a Clang/LLVM. La llegada de Rust introduce nuevos componentes que también hay que tener en cuenta, mantener y auditar, lo que aumenta la superficie de posibles fallos en la infraestructura de compilación.

En este contexto destacan varios proyectos complementarios, como el generador de código de GCC para rustc, un frontend de GCC para Rust que todavía se encuentra en estado alfa, y un port de Coccinelle —la herramienta usada para hacer transformaciones automáticas de código C en el kernel— adaptado al lenguaje originario de Mozilla. Cada una de estas piezas tiene su propio ciclo de maduración y sus posibles bugs, lo cual añade incertidumbre.

Esta dependencia de componentes relativamente nuevos puede resultar incómoda para un proyecto que, en general, prefiere basarse en herramientas probadas durante años o incluso décadas. Cualquier cambio en rustc, en las bibliotecas estándar o en las integraciones con GCC y Clang puede repercutir directamente en la capacidad de compilar el kernel o en la calidad del código generado, y eso obliga a un seguimiento continuo.

Al mismo tiempo, hay que considerar la carga de conocimiento que esto implica. No todos los desarrolladores del kernel están dispuestos a familiarizarse con las particularidades del compilador de Rust, sus flags, sus ciclos de soporte o las herramientas asociadas. Esta brecha de conocimiento puede convertirse en un obstáculo práctico a la hora de revisar parches, diagnosticar errores o mantener código que, en muchos casos, otros escribieron.

Limitaciones estructurales: un kernel gigantesco mayoritariamente en C

Incluso los defensores más entusiastas de Rust reconocen que reescribir el kernel en este lenguaje es irreal a corto y medio plazo. Para 2022, se calculaba que el código del núcleo rondaba los 28 millones de líneas, en su inmensa mayoría en C. Cambiar masivamente esa base tecnológica no solo requeriría un esfuerzo titánico, sino que, además, introduciría una cantidad enorme de riesgo.

En la práctica, Rust está entrando de forma muy gradual y en zonas relativamente acotadas, sobre todo en drivers nuevos y componentes donde el aislamiento es mayor. Esto significa que durante muchos años, probablemente décadas, el kernel será bilingüe, con partes en C y otras en Rust conviviendo y colaborando. Esa convivencia tiene su propia complejidad: hay que definir interfaces claras, garantizar ABI estables y cuidar mucho la interacción entre código de ambos lenguajes.

Desde el punto de vista del mantenimiento, este bilingüismo implica nuevas exigencias. Los revisores y mantenedores deberán decidir qué fragmentos de código son aceptables en Rust, quién se encarga de ellos cuando sus autores originales se marchan y cómo se abordan las refactorizaciones que afectan a zonas híbridas. En un proyecto donde la rotación de colaboradores es constante, confiar demasiado en especialistas muy concretos puede volverse una fuente de fragilidad.

Además, el tamaño del kernel hace que cualquier cambio de paradigma avance con una lentitud enorme. Aunque Rust mejore notablemente la seguridad de las nuevas piezas que se escriban en él, el grueso de las vulnerabilidades seguirá, durante mucho tiempo, en el código C ya existente. Esto relativiza hasta cierto punto el impacto real de Rust en la seguridad global del sistema, al menos en el corto plazo.

Existen también implicaciones indirectas en el ecosistema. Distros, fabricantes de hardware y proyectos relacionados con el kernel deberán asegurarse de que su infraestructura está lista para compilar y probar variantes del núcleo con Rust habilitado. Todo esto añade trabajo a una cadena de valor que ya es compleja de por sí.

Impacto comunitario y cultural: de la guerra C vs Rust al futuro del kernel

Más allá de lo técnico, la historia de Rust en Linux ha sido un choque cultural dentro de la comunidad. Durante años, mucha gente se ha identificado con la forma tradicional de desarrollar el kernel: C, herramientas sobrias, mentalidad conservadora y reglas duras de revisión. La introducción de un lenguaje moderno, con otra filosofía, ha hecho aflorar miedos a perder identidad y a diluir la disciplina que ha mantenido el proyecto en pie.

La llamada “guerra civil” entre el bando de C puro y el bando pro-Rust dejó heridas personales: renuncias, choques públicos, correos muy duros en las listas y acusaciones graves. Linus Torvalds tuvo que intervenir para marcar unas líneas básicas y permitir la integración de Rust con condiciones, lo que rebajó algo la tensión, al menos de forma temporal.

Pese a las fricciones, el kernel ha entrado en una etapa de bilingüismo oficial: C sigue siendo, y seguirá siendo durante muchos años, el idioma predominante, pero Rust ya tiene un hueco propio legítimo. Nuevos drivers y componentes clave podrán escribirse en Rust con respaldo formal del proyecto, lo que abre la puerta a que surja una generación de mantenedores con este lenguaje como herramienta principal.

En paralelo, se ha visto un intento consciente de hacer Linux más atractivo para desarrolladores jóvenes o menos curtidos en las particularidades de C a bajo nivel. Rust, con su ecosistema moderno, sus herramientas de gestión de dependencias y su comunidad activa, puede actuar como puente para quienes, de otra manera, no se atreverían a meterse en el código del kernel.

Al final, la convivencia entre C y Rust en el kernel será un ejercicio de equilibrio constante: aprovechar las ventajas en seguridad y modernidad sin sacrificar estabilidad, rendimiento ni las prácticas que han hecho del núcleo de Linux el corazón del sistema operativo más usado del planeta en servidores, móviles y todo tipo de dispositivos. Las desventajas actuales —dependencia de herramientas jóvenes, fricciones con normas internas, carga extra de mantenimiento y conflictos culturales— son el precio de explorar ese camino, y todavía queda por ver hasta qué punto la balanza se inclinará de forma clara hacia un modelo en el que los lenguajes seguros en memoria sean realmente los protagonistas.

Con todo este contexto encima de la mesa, la adopción de Rust en el kernel Linux se entiende mejor como una transición larga y complicada que combina beneficios evidentes en seguridad con costes tangibles en complejidad, gobernanza y cultura de proyecto; una apuesta que, aunque ya ha pasado de experimento a realidad oficial, seguirá dando que hablar a medida que el código Rust crezca dentro de un mar de C que todavía domina el corazón de Linux.