Desde la concepcion de la idea de integrar un segundo lenguaje de programacion en el Kernel de Linux, hasta la llega de la primera version de Rust for Linux, muchos de los desarrolladores y tambien del equipo del Kernel, se han tenido que acoplar (por asi decirlo) al trabajo con este segundo lenguaje.

Y es que la llega de Rust no fue todo color de rosa, ya que han surgido diversas problematicas entre los desarrolladores de ambos bandos y hasta cierto punto es entendible ya que cada quien debe defender su trabajo. Pero la transición de lenguajes de programación tradicionales hacia alternativas modernas presenta un desafío técnico considerable en la gestion de recursos (tambien hablando del humano).

Es por ello que para abordar esta situación, Canonical ha anunciado una colaboración de investigación con la Universidad de Bristol enfocada en la traducción automática de código C a Rust. Este proyecto, respaldado por un programa de doctorado financiado a tres años, busca desarrollar herramientas capaces de procesar repositorios con cientos de miles de líneas de código y convertirlas en implementaciones de Rust seguras y fáciles de mantener. La iniciativa tiene como objetivo principal reducir los costos y riesgos asociados con la modernización de componentes críticos a nivel de sistema operativo.

Los traductores tradicionales de código fuente a código fuente pueden procesar grandes cantidades de código, pero a menudo conservan la estructura de C de forma demasiado literal. El resultado puede compilarse como Rust, pero aún depende en gran medida de operaciones inseguras, conserva modismos de C poco prácticos y requiere un trabajo manual considerable antes de que se parezca al código que un mantenedor de Rust elegiría como propio.

Los modelos de lenguaje grandes presentan características casi opuestas. Pueden producir código Rust convincente e idiomático para ejemplos pequeños y bien definidos, pero tienen dificultades con el contexto a escala de repositorio. Más importante aún, una salida que parezca plausible no garantiza que el programa traducido se comporte como su código fuente.

Y aun que suena sencillo y muchos pensarian que es como pasar una texto en un traductor, la realidad es que reescribir software escrito en C de manera manual implica un riesgo de ingeniería elevado. Los proyectos establecidos contienen décadas de correcciones de errores, optimizaciones de rendimiento y conocimientos operativos que suelen perderse en el proceso de refactorización.

Es cierto que las herramientas de traducción tradicionales de código fuente logran procesar grandes volúmenes de datos, pero generan un código Rust inseguro que conserva estructuras poco naturales heredadas de C. Por otro lado, los modelos de lenguaje de inteligencia artificial logran generar código en ejemplos pequeños, pero fallan al procesar repositorios enteros debido a los grandes volumentes y terminan perdiendo la idea central, ademas de que no ofrecen garantías de que el programa resultante conserve el comportamiento del código original.

Para superar estas limitaciones, el equipo de investigación propone un modelo híbrido neurosimbólico que combina el aprendizaje automático con métodos clásicos de análisis, pruebas de estrés y verificación formal. El flujo de trabajo se divide en cuatro etapas principales:

• Primero, la fase de programación divide el repositorio masivo en fragmentos independientes, manteniendo el hilosemántico necesario sobre tipos y dependencias.
• La segunda etapa es la fase de traducción emplea modelos de lenguaje ajustados con bibliotecas de conversiones conocidas de C a Rust para generar abstracciones correctas en lugar de una simple copia sintáctica.
• La tercera etapa asume que el código generado no es confiable hasta que técnicas de fuzzing y comprobaciones de equivalencia demuestren que actúa exactamente igual que el código original en C.
• Finalmente, un sistema de depuración localiza los fallos de validación y aplica correcciones precisas mediante técnicas de reparación simbólica.

La viabilidad de esta plataforma se evaluará utilizando componentes de seguridad de Ubuntu, específicamente AppArmor y snap-confine. Estas herramientas actuarán como casos de estudio industriales para comprobar si los métodos desarrollados pueden lidiar con las complejidades de los sistemas de compilación, el manejo intensivo de punteros y los comportamientos específicos de la plataforma que caracterizan al software de producción.

Finalmente, si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

Artículo original