Portada » Greg Kroah-Hartman asegura que con Rust se puede eliminar el 80% de las vulnerabilidades en Linux
Publicado en

Greg Kroah-Hartman asegura que con Rust se puede eliminar el 80% de las vulnerabilidades en Linux

Greg Kroah-Hartman, quien es uno de los principales mantenedores del kernel Linux, aseguró recientemente que el uso del lenguaje de programación Rust evita muchos de los errores que se cometen usando C y los cuales terminan generando vulnerabilidades de seguridad en el kernel Linux. También señalo que C actualmente carece de muchos mecanismos para abordar eficazmente la gestión de datos desde el espacio de usuario y del hardware al kernel. Todo ello podría eliminar hasta en un 80% las vulnerabilidades CVE del núcleo.

el principal mantenedor del kernel Linux, Greg Kroah-Hartman, aseguró que el uso del lenguaje Rust podría eliminar hasta un 80% el número de vulnerabilidades CVE en el kernl Linux.

¿Cuáles son los problemas que presenta C y por qué Hartman asegura que con Rust se pueden eliminar un 80 % de vulnerabilidades CVE en Linux?

De acuerdo con Greg, uno de los principales problemas que presenta el lenguaje C es la manera en que gestiona los datos que llegan desde el espacio del usuario o desde algún controlador de hardware al kernel. Hartman considera que el kernel, por seguridad, debería tratar todos estos datos con mucho recelo. Pero al estar prácticamente compilado con C, no hay una manera fiable de garantizar esta gestión.

«En el espacio de usuario, una vez que los datos se copian y pasan al núcleo, estos se convierten en punteros normales y pierden todo su contexto original, compartiéndose libremente. Los verificadores externos que deberían detectar y controlar esto no siempre se ejecutan. En el caso del hardware sucede algo similar. El kernel Linux se diseñó partiendo del principio de que el hardware es fiable y tampoco hay un detector eficaz que controle esto. C nunca ha tenido un mecanismo que permita gestionar estos problemas de manera confiable». Señaló Hartman.

¡Rust al rescate!

Otro de los problemas que tiene C por el lado de los desarrolladores es que el lenguaje no tiene capacidad de comprobar valores de retorno de error ni liberar bloqueos. En estos casos, muchos desarrolladores pasan por alto la verificación y liberación y esto termina generando vulnerabilidades CVE en el kernel Linux. No obstante, Rust posee características que permiten gestionar ambas situaciones durante el tiempo de compilación. Greg estima que, ya al eliminar estos dos problemas que provocan vulnerabilidades en Linux, se solventaría ya el 60 % de los CVE.

En el caso del problema propio de C con relación a la gestión de datos desde el espacio del usuario al kernel y del hardware, Greg ha propuesto como solución una nueva función de Rust llamada.Untrusted<T>. Esta nueva funcionalidad adjunta los datos que se copian del espacio del usuario o de un controlador de hardware como si fuesen marcadores de tiempo de compilación, sin llegar a impactar los tiempos de ejecución. Al tratarse como marcadores de tiempo de compilación o datos subyacentes, estos no pueden acceder directamente al kernel sin que pasen por un gestor de validación y sean convertidos en datos confiables. Todo este proceso hará que la validación de datos se efectúe en un único lugar y su código sea verificable.

¿Cuándo veremos estos trabajos?

La propuesta de Greg aún está en fases muy tempranas y, de hecho, ni siquiera ha sido propuesta en el upstream de la rama de desarrollo de Linux. Para llevar a buen puerto dicha propuesta, primero se necesitan hacer varios cambios en el compilador de Rust. Luego, y por obviedad, se necesita que más desarrolladores se involucren.

Soy Ramón Marquez, creador y editor jefe de este sitio web. Llevo más de 10 años redactando notas informativas, de opinión y guías sobre tecnología, enfocándome sobre todo en Linux y Windows. Con Notas REM, abarco más segmentos de tecnología como juegos, Apple (Mac e iOS), hardware, móviles y la IA.

Además de la redacción, también tengo amplia experiencia en el soporte TI (nivel 1 y 2), donde he formado parte de equipos de laboratorios de pruebas y equipos de migración de plataforma.

Deja un comentario