Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

Este artículo examina las trampas específicas al implementar máquinas virtuales en CHERI, utilizando la portación de CRuby como estudio de caso para identificar y proponer soluciones a los problemas derivados de suposiciones sobre comportamientos indefinidos en C que son inválidos bajo el modelo de seguridad de memoria más estricto de CHERI.

Lo esencial

¡Claro que sí! Imagina que este artículo es como una historia de un equipo de ingenieros que intentó mover una ciudad antigua y compleja (el lenguaje de programación Ruby y su motor, CRuby) a un nuevo distrito de la ciudad diseñado con reglas de seguridad mucho más estrictas (CHERI).

Aquí tienes la explicación en español, usando analogías sencillas:

🏗️ El Contexto: La Ciudad de los "Pasaportes" (CHERI)

Imagina que en las computadoras normales, las direcciones de memoria son como llaves maestras simples. Si tienes una llave, puedes abrir cualquier puerta en el edificio. Si un ladrón (un error o un hacker) consigue una llave, puede entrar a cualquier habitación, incluso a las que no le corresponden.

CHERI es un nuevo sistema de seguridad donde las "llaves" son en realidad pasaportes inteligentes.

• Cada pasaporte no solo dice dónde estás, sino también cuánto espacio tienes permiso para recorrer (límites) y qué puedes hacer (leer, escribir, ejecutar).
• Si intentas usar ese pasaporte para entrar a una habitación fuera de tu zona permitida, la puerta se cierra automáticamente y te detiene.

🚧 El Problema: Mover la Ciudad Vieja

Los autores del artículo tomaron CRuby (el motor que hace funcionar el lenguaje Ruby, usado en muchas webs y apps) e intentaron moverlo a este nuevo distrito de "Pasaportes".

El problema es que los constructores de CRuby, al trabajar en el sistema antiguo, asumían ciertas cosas que ya no son ciertas en el nuevo sistema. Era como si los arquitectos de la ciudad vieja dijeran: "Siempre que tengas una llave, puedes abrir cualquier puerta". Pero en la nueva ciudad, si intentas eso, el sistema te grita: ¡Alto! Tu pasaporte no te permite entrar aquí.

🔍 Los 6 "Trampas" (Pitfalls) que Encontraron

El equipo descubrió 6 tipos de errores comunes que ocurren cuando intentas aplicar las viejas reglas a las nuevas. Aquí te los explico con analogías:

1. La Trampa del "Mapa Desbordado" (Invalid Derived Pointer)

• La situación: En el sistema viejo, si tenías una llave para una habitación pequeña, podías usarla para caminar por todo el pasillo.
• El error: En CRUBY, a veces toman una llave de una habitación pequeña (una variable local) y dicen: "Ahora usaré esta llave para recorrer todo el pasillo".
• El resultado: En el nuevo sistema, el pasaporte de la habitación pequeña no te deja salir de ella. Intentas caminar un paso más y el sistema te detiene porque tu pasaporte dice "Solo puedes estar aquí".
• La solución: En lugar de usar la llave pequeña, guardan un "Pasaporte Maestro" que cubre todo el edificio y lo usan para navegar.

2. La Trampa de la "Llave Fantasma" (Dereferencing Ambiguous Pointers)

• La situación: El sistema de seguridad de Ruby (el recolector de basura o GC) revisa todo lo que hay en la memoria para ver si es una "llave real" o solo un número cualquiera. En el sistema viejo, miraban la forma del número: "Si parece una llave, debe ser una llave".
• El error: En CRUBY, a veces un número cualquiera tiene la misma forma que una llave, pero no tiene el sello de seguridad (el "tag" o validación). El sistema intenta abrir la puerta con esa "llave fantasma" y falla.
• La solución: En lugar de adivinar por la forma, el sistema ahora mira el sello de seguridad del pasaporte. Si no tiene el sello, sabe que no es una llave real y no intenta abrirla. ¡De hecho, esto hace que el sistema sea más rápido porque no pierde tiempo revisando números falsos!

3. La Trampa de la "Ampliación en el Sitio" (In-Place Reallocation)

• La situación: Imagina que tienes una caja de herramientas y necesitas hacerla más grande. En el sistema viejo, si la caja se hacía más grande en el mismo lugar, podías seguir usando la misma etiqueta de "Caja de Herramientas" sin problemas.
• El error: En CRUBY, cuando la caja se hace más grande, el sistema te da una nueva etiqueta con un nuevo límite de tamaño. Si sigues usando la etiqueta vieja para guardar herramientas en la parte nueva de la caja, el sistema te detiene porque tu etiqueta vieja dice "Solo puedes llegar hasta aquí".
• La solución: Debes actualizar todas las etiquetas viejas con la nueva etiqueta que te dio el sistema. O mejor aún, no depender de que la caja se agrande en el mismo sitio.

4. La Trampa de los "Bits de Relleno" (Using Padding Bits)

• La situación: Los programadores de Ruby a veces guardan muchos datos pequeños dentro de un solo número grande, como si fuera un contenedor de huevos. Asumían que todos los huecos del contenedor estaban disponibles.
• El error: En CRUBY, esos contenedores grandes (llamados uintptr_t) tienen una mitad de "huecos de seguridad" (metadatos) que no se pueden tocar. Si intentas guardar datos en esos huecos de seguridad, el sistema se confunde o ignora lo que escribiste.
• La solución: Usar contenedores más pequeños y exactos (como uint64_t) que no tengan esos huecos de seguridad ocultos, para que todo el espacio sea utilizable.

5. La Trampa de los "Pasaportes Sellados" (Modifying Temporary Capabilities)

• La situación: Hay ciertos pasaportes que están sellados con lacre (como los de retorno de una función). No se pueden tocar ni modificar.
• El error: El sistema de Ruby a veces intenta hacer cálculos matemáticos con estos pasaportes sellados (como sumar o restar para encontrar un número). Al intentar tocar el lacre, el sistema explota (error de seguridad).
• La solución: Antes de hacer el cálculo, el sistema debe "desempacar" el pasaporte, sacar solo el número que necesita, hacer el cálculo con el número, y listo. No tocar el pasaporte sellado en sí.

6. La Trampa de la "Aritmética de Punteros" (Pointer Arithmetic on Non-Capability Type)

• La situación: A veces los programadores convierten una llave en un número, hacen una resta y la vuelven a convertir en llave. En el sistema viejo, funcionaba con cualquier tipo de número.
• El error: En CRUBY, si usas un tipo de número incorrecto (como size_t en lugar de uintptr_t) para hacer la conversión, al volver a convertirlo en llave, el pasaporte queda roto (pierde sus límites y permisos).
• La solución: Usar siempre el tipo de número correcto (uintptr_t) que sabe cómo guardar la información del pasaporte completo.

📊 ¿Qué pasó con la velocidad?

El equipo se preguntó: "¿Todo esto hace que Ruby sea más lento?".

• Resultado: ¡Sorprendentemente no! En la mayoría de las pruebas, la velocidad fue casi idéntica (el 98% de la velocidad original).
• La excepción: Solo hubo un problema con una función muy específica llamada "Fibers" (que permite hacer varias cosas a la vez), donde la versión nueva fue un poco más lenta porque tuvieron que usar una solución general en lugar de una optimizada para el hardware viejo.

💡 La Lección Final

Este artículo nos enseña que la seguridad tiene un precio, pero no siempre es alto.

• Para hacer programas más seguros en el futuro, los desarrolladores deben dejar de asumir cosas que "funcionan por suerte" en los sistemas viejos.
• Deben ser más estrictos: usar los tipos de datos correctos, verificar los sellos de seguridad y no confiar en trucos de "hacerlo funcionar" que rompen las reglas de los nuevos pasaportes inteligentes.

En resumen: Mover Ruby a CHERI fue como enseñar a un conductor a manejar en una ciudad con semáforos y cámaras de seguridad estrictas. Al principio chocó contra las paredes porque intentaba conducir como en la autopista vieja, pero con las correcciones adecuadas, ahora circula de forma segura y casi tan rápido como antes.

Resumen técnico

Resumen Técnico: Trampas en la Implementación de VMs en CHERI

1. Problema

La seguridad del software es crítica, especialmente en las Máquinas Virtuales (VMs) de lenguajes de programación, que actúan como base para muchos servicios modernos. Aunque las VMs buscan proporcionar entornos seguros, ellas mismas contienen vulnerabilidades de memoria. CHERI (Instrucciones RISC Mejoradas con Hardware de Capacidades) es una arquitectura que aborda estos problemas reemplazando los punteros tradicionales por capacidades (tokens inalterables con metadatos de límites y permisos).

Sin embargo, portar VMs existentes a CHERI es una tarea compleja y no trivial. El problema central radica en que los desarrolladores de VMs suelen basar sus implementaciones en comportamientos indefinidos (undefined behavior) del lenguaje C o en suposiciones sobre arquitecturas tradicionales que son inválidas bajo el modelo de seguridad estricto de CHERI.

• Brecha de conocimiento: Aunque existen guías generales para programar en CHERI y trabajos previos sobre la portación de VMs (como MicroPython o JavaScriptCore), faltan estudios específicos que categoricen y analicen las trampas (pitfalls) únicas de la implementación de VMs en este entorno.
• Consecuencia: Las asunciones incorrectas sobre el comportamiento de los punteros, la aritmética de enteros y la gestión de memoria provocan fallos inesperados (como violaciones de etiquetas o límites) al ejecutar VMs en CHERI.

2. Metodología

Los autores abordaron el problema mediante un estudio de caso práctico y una revisión sistemática:

• Estudio de Caso (Portación de CRuby): Portaron CRuby (la implementación de referencia de Ruby, escrita en C) a la arquitectura CHERI en modo purecap (solo capacidades).
  • Alcance: Se centraron en el sistema de tiempo de ejecución y el intérprete, excluyendo el compilador JIT y la interfaz de funciones externas (FFI).
  • Proceso: Compilaron el código con el compilador CHERI, corrigieron errores de compilación y ejecutaron las suites de pruebas (basictest, bootstraptest, test).
  • Resultados iniciales: De 34,046 casos de prueba, 29,609 pasaron. Los fallos restantes se debieron principalmente a un colapso en una prueba de árboles de sintaxis abstracta (debido a un problema no resuelto) y a la falta de la librería libyaml.
• Revisión de Trabajos Previos: Analizaron tres casos de estudio anteriores: MicroPython, JavaScriptCore y el port de Rust a CHERI.
• Categorización: Clasificaron los problemas encontrados en seis categorías principales basadas en sus causas raíz, contrastando los hallazgos de CRuby con los de los otros proyectos.
• Evaluación de Rendimiento: Compararon el rendimiento de la VM de Ruby portada frente a la original (x86) utilizando 894 micro-benchmarks oficiales.

3. Contribuciones Clave y Categorización de Trampas

El artículo identifica y analiza seis categorías de trampas específicas para VMs en CHERI, muchas derivadas de comportamientos indefinidos en C:

1. Punteros Derivados Inválidos (Invalid Derived Pointer):

   • Problema: Las VMs a menudo derivan un puntero para un propósito diferente al original (ej. escanear la pila tomando la dirección de una variable local). En arquitecturas tradicionales esto funciona, pero en CHERI, el operador & devuelve una capacidad con límites estrictos solo para esa variable. Derivar un puntero para escanear toda la pila a partir de ella viola los límites.
   • Solución: Mantener una "super-capacidad" con límites amplios (ej. toda la pila) y derivar los punteros de trabajo desde ella.

2. Desreferenciación de Punteros Ambiguos (Dereferencing Ambiguous Pointers):

   • Problema: Los recolectores de basura conservadores (GC) tratan cualquier valor que parezca un puntero (patrón de bits) como un puntero real. En CHERI, convertir un entero arbitrario a puntero no establece la etiqueta de validez, causando fallos al desreferenciar.
   • Solución: Verificar la etiqueta de validez (validity tag) antes de desreferenciar, en lugar de confiar solo en el patrón de bits. Esto permite un escaneo más preciso y elimina la necesidad de "fijar" (pinning) objetos.

3. Reasignación en el Lugar (In-Place Reallocation):

   • Problema: Las VMs a menudo asumen que realloc devuelve el mismo puntero si la reasignación es en el mismo lugar. En CHERI, realloc puede devolver una capacidad con límites más amplios, invalidando el puntero antiguo si este tenía límites ajustados.
   • Solución: No depender de la reasignación en el lugar. Si es necesario, actualizar todas las referencias al puntero antiguo con el nuevo puntero devuelto.

4. Uso de Bits de Relleno (Padding Bits) en Tipos Enteros:

   • Problema: Las VMs empaquetan datos en enteros (mapas de bits, campos de bits). En CHERI, los tipos (u)intptr_t son capacidades de 128 bits; los 64 bits superiores son metadatos (relleno). Operaciones de desplazamiento (shift) o máscaras que asumen un ancho de 64 bits completos fallan o producen resultados aleatorios.
   • Solución: Usar tipos enteros de ancho exacto (ej. uint64_t) para operaciones de bits, evitando los tipos de puntero.

5. Modificación de Capacidades Temporales Introducidas por el Compilador:

   • Problema: Las operaciones binarias en (u)intptr_t pueden generar capacidades temporales que heredan metadatos. Si el operando original es una capacidad sellada (ej. direcciones de retorno), intentar modificar su dirección (incluso para cálculos aritméticos) provoca fallos de capacidad sellada.
   • Solución: Convertir los operandos a tipos no-capacidad (ej. uint64_t) antes de realizar operaciones aritméticas si el resultado no necesita ser un puntero válido.

6. Aritmética de Punteros en Tipos No-Capacidad:

   • Problema: Castear punteros a tipos enteros genéricos como size_t para hacer aritmética y luego castearlos de vuelta es común (ej. para herencia de clases en C). En CHERI, si size_t no es un tipo de capacidad, la capacidad se pierde y el puntero resultante es inválido.
   • Solución: Usar exclusivamente (u)intptr_t para la aritmética de punteros para garantizar la recuperación de la capacidad original.

4. Resultados

• Corrección de Errores: Se identificaron y corrigieron 464 líneas de código en 40 archivos de CRuby (aprox. 0.077% del código total) para resolver las trampas descritas.
• Rendimiento:
  • En promedio, la VM de Ruby portada a CHERI alcanzó un 98.2% del rendimiento de la VM original en x86 (desviación estándar de 0.038).
  • La mayoría de los benchmarks mostraron una relación de rendimiento cercana a 1.0.
  • Outliers: Algunos benchmarks relacionados con fibers (corutinas) mostraron un rendimiento hasta 10 veces peor. Esto se debió a que la implementación original de Ruby usa ensamblador optimizado para x86, mientras que la versión portada usa una implementación genérica basada en funciones de librería estándar.
• Impacto de las Soluciones:
  • La mayoría de las soluciones (como el uso de tipos enteros exactos o la verificación de etiquetas) no introdujeron sobrecarga de rendimiento.
  • Algunas soluciones, como mantener super-capacidades con límites amplios, pueden tener un impacto en la seguridad (mayor superficie de ataque si no se segmentan), pero son necesarias para la funcionalidad.

5. Significado e Impacto

Este trabajo es fundamental para la adopción de CHERI en sistemas de tiempo de ejecución complejos:

1. Guía Práctica: Proporciona un catálogo detallado de trampas específicas para VMs, llenando el vacío entre las guías generales de programación en CHERI y la realidad de portar sistemas complejos.
2. Validación de Viabilidad: Demuestra que es posible portar VMs complejas escritas en C (como CRuby) a CHERI con un costo de rendimiento mínimo y un alto grado de compatibilidad.
3. Mejora de Seguridad: Al corregir estos comportamientos indefinidos, las VMs portadas no solo funcionan en CHERI, sino que se vuelven inherentemente más seguras, eliminando vulnerabilidades de memoria latentes que existían en las versiones tradicionales.
4. Lecciones para Futuros Desarrollos: Establece que los desarrolladores de VMs deben abandonar las optimizaciones basadas en suposiciones de arquitecturas tradicionales (como la intercambiabilidad total de enteros y punteros) y adoptar prácticas que respeten el modelo de capacidades.

En conclusión, el artículo establece las bases para construir VMs más seguras y portables en arquitecturas de hardware seguro, demostrando que los desafíos de implementación son manejables mediante cambios de diseño específicos y no requieren una reescritura completa del sistema.