Rust es ahora oficial en el kernel de Linux — y la seguridad de memoria se está convirtiendo en política de seguridad
La mejora de seguridad más trascendental en la historia de la computación podría no ser un nuevo esquema de autenticación, un firewall más inteligente o un mejor sistema de detección. Podría ser cambiar el lenguaje de programación en el que están escritos los sistemas operativos.
Las vulnerabilidades de seguridad de memoria — errores de use-after-free, desbordamientos de búfer, desreferencias de puntero nulo, desbordamientos de enteros que se convierten en desbordamientos de búfer — han representado aproximadamente el 70% de los CVEs de alta gravedad de Microsoft durante años. Google reporta cifras similares para Chrome y Android. La NSA ha publicado guías que indican que alrededor del 70% de todas las vulnerabilidades de software explotables son problemas de seguridad de memoria. Estos no son casos extremos oscuros — son la clase más común de vulnerabilidad explotable, y han sido comunes durante cuarenta años porque la mayor parte del código del sistema operativo está escrito en C y C++, lenguajes que facilitan escribir código inseguro en memoria y dificultan detectar los errores hasta que algo falla en producción.
Rust elimina toda la categoría. No agregando un recolector de basura en tiempo de ejecución — Go y Java toman ese enfoque, y cuesta rendimiento que los sistemas operativos no pueden permitirse. En su lugar, Rust utiliza un borrow checker en tiempo de compilación que rastrea la propiedad y los tiempos de vida de cada pieza de memoria en tiempo de construcción. Si escribes código que podría producir un error de use-after-free, el compilador de Rust se niega a compilarlo. El error de memoria no ocurre en tiempo de ejecución. Falla en tiempo de compilación con un mensaje de error que te dice exactamente qué está mal. Sin fallo, sin CVE, sin ciclo de parches, sin hotfix de emergencia enviado a las 3 AM.
El hito del kernel de Linux
El kernel de Linux es la base de Android, la mayor parte de la infraestructura en la nube y una vasta gama de sistemas embebidos. También está escrito casi completamente en C — aproximadamente 27 millones de líneas acumuladas durante treinta años. Agregar un nuevo lenguaje de programación a una base de código tan antigua y crítica es una decisión que requiere años de validación antes de convertirse en política oficial.
El primer código Rust se fusionó en el kernel de Linux con el lanzamiento 6.8 en diciembre de 2023. Las implementaciones iniciales cubrieron el controlador GPU Asahi (soportando Macs Apple M1 y M2 ejecutando Linux) y algo de infraestructura del controlador NVMe — áreas donde se estaba desarrollando nuevo código y donde se minimizaba el riesgo de romper funcionalidad existente. Esto fue una prueba de concepto de que Rust podía operar dentro de las estrictas restricciones del kernel y coexistir con la base de código C existente.
En diciembre de 2025, el proyecto del kernel de Linux declaró oficialmente que Rust en el kernel ya no era experimental. El desarrollo de Rust en el kernel ahora es parte oficial del proceso de desarrollo del kernel, con las mismas garantías de estabilidad, requisitos de prueba y estándares de revisión de código que el desarrollo en C. Los nuevos subsistemas del kernel pueden escribirse en Rust con la confianza de que Rust seguirá siendo un lenguaje soportado del kernel a largo plazo — un compromiso que antes no podía hacerse porque la designación experimental significaba que la infraestructura de Rust en el kernel podía eliminarse si no funcionaba.
Esto importa prácticamente por varias razones. Los desarrolladores de controladores pueden escribir nuevos controladores en Rust sin incertidumbre sobre si la infraestructura de Rust en el kernel existirá en la próxima versión del kernel. Los componentes del kernel críticos para la seguridad — pilas de red, controladores de sistema de archivos, subsistemas criptográficos — pueden reescribirse sistemáticamente en Rust con el tiempo, reduciendo la superficie de ataque de código que actualmente se ejecuta con privilegios ring-0 y procesa entrada externa no confiable. Y señala a la comunidad más amplia de programación de sistemas que Rust es una opción seria a largo plazo para trabajo en kernel, lo que afecta decisiones de contratación, capacitación e inversión en herramientas en toda la industria.
La adopción de Rust en Android y sus resultados
Google comenzó a agregar Rust a Android en 2021 y ha sido el más transparente al medir los resultados. Para 2024, Google informó que aproximadamente el 77% del nuevo código de Android está escrito en Rust — una cifra que refleja el nuevo código que se agrega a la plataforma, no la base de código C y C++ existente, que permanece en gran parte como está escrita y sigue manteniéndose.
El impacto medible en seguridad es significativo. La tasa de vulnerabilidades de seguridad de memoria descubiertas en Android ha disminuido año tras año desde 2019, el mismo período en que comenzó la adopción de Rust. Google atribuye esto directamente a la elección del lenguaje: el código Rust que se ejecuta en Android no produce CVEs de seguridad de memoria al mismo ritmo que el código C, porque el compilador previene toda la clase de errores antes de que el código se envíe.
La pila Bluetooth de Android, partes de la pila de red y componentes de la infraestructura de códecs multimedia han sido reescritos en Rust. Estas son exactamente las superficies de ataque que históricamente han producido vulnerabilidades de alta gravedad — procesan entrada externa no confiable (paquetes de emparejamiento Bluetooth, datos de red, archivos de video de fuentes no confiables) con lógica de análisis compleja donde un solo error off-by-one puede convertirse en una vulnerabilidad de ejecución remota de código explotable sin interacción del usuario.
El enfoque de Microsoft
La adopción de lenguajes seguros en memoria por parte de Microsoft está distribuida en varias iniciativas en lugar de un solo mandato centralizado. El equipo del kernel de Windows ha estado evaluando Rust para el desarrollo de nuevos controladores de kernel, y Microsoft contribuye activamente al proyecto Rust para Windows que proporciona bindings de Rust a las API de Windows. La infraestructura de Azure ha adoptado Rust en varios componentes. El proyecto Hyperlight de Microsoft — un hipervisor ligero diseñado para ejecutar funciones serverless a escala — fue construido en Rust desde cero.
Más ampliamente, Microsoft se ha comprometido a escribir nuevo código crítico para la seguridad en lenguajes seguros en memoria (que incluye Rust, Go y C# junto con los lenguajes seguros más antiguos Swift y Java) y reescribir sistemáticamente el código C y C++ existente en alternativas seguras en memoria donde el riesgo de seguridad justifique el costo de ingeniería. Esto no es un mandato de "reescribir todo en Rust" — es un enfoque priorizado por riesgo que enfoca las reescrituras seguras en memoria en código que maneja entrada externa y se ejecuta con privilegios elevados, que es exactamente donde los errores de memoria se traducen en vulnerabilidades explotables.
Los verdaderos desafíos
Las garantías de seguridad de memoria de Rust vienen con verdaderas compensaciones que importan para la adopción en el mundo real:
La curva de aprendizaje es empinada. El borrow checker impone reglas de propiedad que se sienten desconocidas para los desarrolladores que vienen de C, C++ o la mayoría de otros lenguajes. "Pelear con el borrow checker" es una frustración común para los desarrolladores nuevos en Rust. Google estima que se necesitan de seis meses a un año para que un desarrollador experimentado en C se vuelva genuinamente productivo en Rust en una base de código grande. A escala, esto es una inversión significativa en capacitación y contratación.
La interoperabilidad con C es necesaria pero compleja. Cualquier estrategia de migración realista implica que Rust llame a C y que C llame a Rust — cruzando el límite FFI entre los dos lenguajes. Ese límite requiere bloques unsafe de Rust, que pueden introducir los mismos errores de memoria que Rust previene. Lograr que los límites FFI funcionen correctamente requiere ingeniería cuidadosa, y cada bloque unsafe necesita una revisión cuidadosa.
Los tiempos de compilación son más largos. El análisis del borrow checker es computacionalmente costoso. Las bases de código grandes en Rust compilan significativamente más lento que las bases de código equivalentes en C, lo que afecta la velocidad de iteración del desarrollador y los tiempos de los pipelines CI/CD. Este es un problema conocido en el que el equipo de Rust está trabajando activamente, pero sigue siendo un costo real.
La base de código existente no va a desaparecer rápidamente. El kernel de Linux tiene 27 millones de líneas de C. Migrar esto incrementalmente a Rust llevará muchos años, y el código C existente seguirá produciendo vulnerabilidades de seguridad de memoria durante toda esa transición. El cambio a lenguajes seguros en memoria es estructural y generacional — previene nuevas vulnerabilidades en código nuevo, no errores existentes en código existente.
La dimensión política
El desarrollo más significativo reciente no es un hito técnico — es el cambio de recomendación técnica a política de seguridad. CISA, la NSA y sus equivalentes de los Five Eyes han publicado guías formales que establecen que los desarrolladores de software tienen la responsabilidad de usar lenguajes seguros en memoria para nuevo código crítico para la seguridad. La Estrategia Nacional de Ciberseguridad de la Casa Blanca menciona explícitamente la seguridad de memoria. Este marco cambia la ecuación para las organizaciones que escriben software que maneja datos sensibles o infraestructura crítica.
Ya no es puramente una decisión técnica. Es una cuestión de si una organización puede defender sus elecciones de lenguaje ante reguladores, auditores y clientes. La combinación de madurez técnica — las herramientas, el ecosistema y la documentación de Rust han mejorado dramáticamente desde 2021 — y la presión política formal está acelerando la adopción más allá de lo que el caso técnico solo impulsaría.
La seguridad de memoria es un problema resuelto en la teoría de lenguajes de programación. Convertirla en el defecto práctico en la infraestructura de sistemas operativos es un proyecto de ingeniería generacional. El hito del kernel de Linux, las métricas de adopción de Android y el cambio de política indican que ese proyecto ha pasado de ejercicio académico a realidad de ingeniería — lentamente, con bordes ásperos y en una escala de tiempo medida en décadas en lugar de ciclos de producto. La dirección es clara y el impulso es real.