Asterinas - un nuevo proyecto de kernel compatible con Linux

 (lwn.net)
8 puntos por GN⁺ 2025-06-23 | 2 comentarios | Compartir por WhatsApp
  • Un kernel compatible con la ABI de Linux escrito en Rust, que busca combinar las ventajas de los kernels monolíticos y los microkernels mediante una arquitectura de “framekernel”
  • Diseñado para encapsular todo el código unsafe dentro de bibliotecas limitadas, permitiendo que el resto de los servicios del kernel se desarrollen con abstracciones seguras de Rust, logrando al mismo tiempo seguridad de memoria y una estructura simple de memoria compartida
  • Su diferencia frente a otros OS en Rust como RedLeaf, Tock y Rust for Linux está en el soporte de aislamiento por hardware, propósito general, ABI compatible con Linux y ejecución de espacio de usuario en varios lenguajes
  • Impulsa la minimización de la TCB (base de cómputo confiable) y la verificación formal (con Verus), además de soporte para hardware de entornos de ejecución confiable como Intel TDX, y también ofrece por separado frameworks de desarrollo de OS como OSTD/OSDK
  • Aún está en una etapa temprana de desarrollo: soporta x86/RISC-V e implementa 206 syscalls; está enfocado en entornos Docker/contenedores/cloud, aunque también está probando expansión hacia escritorio con X11/Xfce

¿Qué es Asterinas?

  • Asterinas es un nuevo proyecto de kernel compatible con la ABI de Linux desarrollado en Rust
  • La arquitectura “framekernel” consiste en limitar el código Rust unsafe (zonas inseguras de memoria) a bibliotecas del framework, envolverlo con APIs seguras, y diseñar el resto de los servicios del kernel para que se desarrollen completamente en Rust seguro
  • Busca al mismo tiempo la estructura simple y de alto rendimiento de un kernel monolítico y la minimización de la TCB (base de cómputo confiable) y seguridad de un microkernel
  • Dentro del kernel, los servicios operan separados dentro del mismo espacio de direcciones, y cada servicio solo puede usar los recursos asignados por la biblioteca core

Explicación de la arquitectura framekernel

  • El concepto de framekernel fue propuesto por primera vez en el artículo "Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation"
  • Un kernel monolítico incluye todo el código dentro de un único espacio de direcciones en modo kernel, mientras que un microkernel asigna espacio de kernel solo a una TCB mínima y delega la mayoría de las funciones a servicios en modo usuario
  • El framekernel encapsula como bibliotecas el código que requiere la funcionalidad unsafe de Rust, y desarrolla el resto de los servicios del kernel con abstracciones de Rust seguras en memoria
  • Cada servicio se ejecuta dentro del espacio de direcciones del kernel, pero está restringido para acceder solo a los recursos provistos explícitamente por la biblioteca
  • Mantener una TCB pequeña hace que la verificación formal (prueba matemática) sea más factible, y puede aumentar la confiabilidad y estabilidad del sistema completo
  • Es un enfoque que combina una base de memoria compartida (alto rendimiento, como un kernel monolítico) con separación interna de privilegios/seguridad (ventajas de un microkernel)

Comparación con otros OS en Rust y con el framekernel

  • RedLeaf: microkernel basado en Rust, no usa aislamiento por hardware
  • Asterinas: OS de propósito general, aprovecha aislamiento por hardware, es compatible con la ABI de Linux y soporta la ejecución de espacio de usuario en varios lenguajes
  • Tock: orientado a SoC embebidos, separa core (permite unsafe) y cápsulas (código seguro), pero no soporta aislamiento por hardware
  • El proyecto Rust for Linux también busca envolver las interfaces del kernel con abstracciones seguras para poder escribir drivers del kernel en Rust de forma segura

Verificación formal y seguridad

  • El objetivo principal de reducir la TCB es hacer realistamente posible la verificación formal
  • Asterinas es el único caso que apunta simultáneamente a una TCB pequeña y verificable como seL4, compatibilidad con la ABI de Linux y una estructura de memoria compartida
  • Está realizando trabajo de verificación formal basado en Verus en colaboración con la empresa especializada en auditorías de seguridad CertiK
    • En el informe de evaluación de seguridad de CertiK se publican los puntos auditados y los problemas encontrados en el proyecto

Bibliotecas y herramientas de desarrollo

  • Además del kernel en sí, ofrece OSTD (framework de OS en Rust) y OSDK (herramienta de desarrollo basada en Cargo)
  • Objetivos principales de OSTD:
    • Reducir la barrera de entrada al desarrollo de OS y sentar bases para la innovación
    • Reforzar la seguridad de memoria de sistemas operativos en Rust y abstraer APIs de bajo nivel
    • Fomentar la reutilización de código entre proyectos de OS en Rust
    • Permitir probar código nuevo en modo usuario (aumentando la productividad de desarrollo)
  • Los kernels basados en OSD y OSTD no necesitan ser compatibles con Linux, y proporcionan APIs seguras en memoria de alto nivel para control de hardware x86, memoria virtual, multiprocesamiento (SMP), temporizadores, etc.
  • Intel participa como patrocinador, especialmente por la afinidad con Trust Domain Extensions (TDX) y tecnologías de aislamiento de máquinas virtuales

Estado del desarrollo y principales patrocinadores

  • Fue publicado por primera vez como open source (licencia MPL) a inicios de 2024; actualmente tiene 45 contribuidores, y los principales vienen de SUSTech, la Universidad de Pekín, la Universidad de Fudan y Ant Group
  • Soporta x86 y RISC-V, e implementa 206 syscalls de Linux (de un total de 368)
  • Todavía no puede ejecutar aplicaciones; apunta al desarrollo de una distribución inicial y soporte para contenedores (Docker), y también prueba una distribución basada en Nix
  • No soporta la carga de módulos del kernel de Linux ni tiene planes de adoptarla de forma permanente

Planes a futuro

  • Toma como prioridades de corto plazo ampliar el soporte para más arquitecturas de CPU, más hardware y la usabilidad real dentro de entornos cloud
  • Ya completó el soporte para dispositivos Linux virtio y tiene como objetivo principal el mercado cloud chino (Alibaba Cloud, Aliyun)
  • Su meta central es desarrollar un host OS para contenedores con TCB reducida y segura, y soporte para capacidades de cómputo confiable de Intel
  • Aunque su objetivo se parece al de Rust for Linux, Rust for Linux se limita a rustificar drivers dentro del kernel existente, mientras que Asterinas busca un rediseño completo del kernel y la minimización de la TCB
  • Actualmente también experimenta con varias direcciones, como soporte para X11 y Xfce, y el propio OSTD podría tener potencial para atraer atención de desarrolladores generales de OS

Diferencias con Rust for Linux

  • Rust for Linux: introduce solo drivers seguros en Rust dentro del kernel Linux existente; el kernel completo sigue basado en C
  • Asterinas: implementa un kernel nuevo desde cero en Rust, restringe estrictamente unsafe, impulsa la verificación formal y se enfoca en entornos cloud/contenedores

Resumen y perspectivas

  • Asterinas está intentando un enfoque innovador en seguridad de memoria, verificación formal y utilidad práctica en entornos cloud
  • Todavía no hay ejemplos de uso real ni una validación amplia de la comunidad, pero está atrayendo interés en investigación de OS, cloud y seguridad
  • Frameworks como OSTD podrían tener utilidad futura dentro del ecosistema de desarrollo de OS en Rust

Resumen de los principales puntos de los comentarios en LWN sobre Asterinas

  • Debate sobre Singularity OS y los límites de seguridad basados en lenguaje
    • El framekernel de Asterinas es similar a Singularity OS de Microsoft, pero aprovecha el borrow checker de Rust para mejorar la seguridad de memoria
    • Sobre el enfoque de proteger sistemas con límites de seguridad del propio lenguaje (por ejemplo Rust, Java, WASM/JS), se enfrentan las críticas de que "la confianza total es imposible y en la práctica se usa junto con sandboxing a nivel hardware/OS" frente a la postura de que "sí ofrece ventajas para prevenir fallos y hacer verificación formal"
    • Aunque WASM, JS y Java también tienen controversias sobre seguridad, en servicios reales no se confía solo en el sandbox del lenguaje; en la práctica es común combinarlo obligatoriamente con sandboxing de hardware o del OS
  • Tendencias en desarrollo de sistemas operativos y contexto geopolítico
    • En los últimos años han aparecido diversos proyectos nuevos de OS, lo que está expandiendo un clima de innovación en sistemas operativos
    • China está acelerando el desarrollo de OS alternativos a Linux para responder a las sanciones tecnológicas de EE. UU. y a los riesgos en la cadena de suministro
    • Siguen con intensidad los debates políticos sobre sanciones de EE. UU., la gobernanza global del open source como GPL, y la necesidad de que regiones como China y Europa busquen ecosistemas tecnológicos independientes
    • También son tema de discusión la dificultad de mantener un fork de Linux frente a desarrollar un kernel totalmente nuevo, la dependencia del conocimiento y know-how de la comunidad, y las barreras idiomáticas
  • Debate sobre compatibilidad con Linux y número de syscalls
    • Hay muchas opiniones de que medir compatibilidad por cantidad de syscalls de Linux es inapropiado
    • Como una sola syscall (ioctl, por ejemplo) puede incluir muchísimas APIs detalladas, para medir compatibilidad real es más importante ejecutar aplicaciones reales y usar suites de pruebas del kernel
    • También aparece la opinión pragmática, citando la historia temprana de Linux cuando se implementaban syscalls una por una para lograr compatibilidad POSIX, de que si se soporta el 99% de las syscalls clave ya podría funcionar bastante software
  • Licenciamiento y ecosistema Rust
    • Hubo discusión sobre la elección de MPL por parte de Asterinas: existe la opinión positiva de que MPL encaja bien con el ecosistema de crates de Rust y con licencias modulares
    • También está la visión de que GPL no siempre es la mejor opción y que, si hay patrocinio corporativo, se podría usar una licencia más amigable para empresas como MPL
  • Dependencias del proyecto/seguridad
    • Se plantean dudas sobre si es seguro usar muchos crates externos en un OS basado en Rust, y se menciona la necesidad de automatizar seguridad y auditoría de la cadena de suministro con herramientas como cargo deny/vet
    • También se comenta que con solo el lockfile es difícil entender la superficie de dependencias, además de la complejidad propia del ecosistema Rust: dependencias transitivas, dependencias por OS, etc.
  • Inspiración técnica/arquitecturas similares
    • Se señala que el concepto de framekernel es similar a la arquitectura SPIN OS de la University of Washington en los años 90
    • SPIN también enfatizaba modularidad fuerte y control de interfaces/acceso por parte del compilador
  • Controversia sobre la composición de committers
    • Se menciona que, entre los 45 contribuidores, muchos commits se concentran en un pequeño grupo de estudiantes de doctorado
    • También se señala que es un error suponer que las contribuciones lideradas por estudiantes de PhD tienen poco valor como committers reales, y que siguen siendo significativas como proyecto innovador orientado a la investigación
  • Debates políticos/históricos y señalamientos de off-topic
    • La discusión sobre OS se extendió hacia debates geopolíticos, políticos e históricos sobre EE. UU., Europa y China, y los editores advirtieron varias veces que era "off-topic"
    • Algunos usuarios enfatizaron que el ecosistema open source/FOSS también puede verse afectado por cambios en el entorno geopolítico
  • Otros
    • Se compartieron artículos académicos sobre la seguridad de WASM
    • Hay una mezcla de miradas positivas y críticas sobre el estado del desarrollo del kernel

Lecturas relacionadas

2 comentarios

 
eususu 2025-06-24

Este tipo de intentos se ven muy bien.
Hasta dan ganas de pensar que pronto aparecerá un kernel que no muera.
 
GN⁺ 2025-06-23
Opiniones en Hacker News

  • Me parece un enfoque interesante y espero que tenga éxito. Pero sigo teniendo dudas. Todavía recuerdo algo que dijo Linus sobre los competidores en una entrevista de TV a fines de los 90 o principios de los 2000. Dijo algo como: "A nadie le gusta escribir drivers, así que estamos a salvo hasta que aparezca algún joven hambriento que resulte ser un excelente ingeniero de drivers". Ya en ese entonces era consciente de que mantener inestable la interfaz de drivers era una medida defensiva. Han pasado 25 años y, aunque los kernels que corren sobre hardware virtualizado son muy comunes, todavía se pueden contar con los dedos los sistemas operativos realmente prácticos y utilizables que hayan logrado abstraerse del hardware real

    • Sobre eso de que "mantener inestable la interfaz de drivers es una medida defensiva", creo que en el futuro podría aparecer algún joven investigador de sistemas, o una IA, y que agentes de IA traduzcan drivers de Linux escritos en C a drivers seguros en Rust para Asterinas. Otro enfoque realista es reutilizar el propio kernel de Linux metiéndolo dentro de algún entorno aislado. Por ejemplo, el kernel de HongMeng reutiliza drivers usando User-Mode Linux. Asterinas también podría aplicar una estrategia similar. Referencia: https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • Tengo mis dudas de que Linus realmente quisiera o pretendiera una "barrera defensiva". No es el fundador de una startup tecnológica; originalmente era simplemente un hacker del kernel y ya tenía asegurada su vida económica. Interpretar la inestabilidad de la interfaz de drivers dentro del kernel como una estrategia deliberada para frenar a la competencia me parece una proyección exagerada

    • Ya hubo precedentes como SPIN OS (Modula 3), JX OS (Java), House OS (Haskell) y Verve. Todos implementaron funciones del kernel usando lenguajes con type safety y memory safety. En general, estructuraban el riesgo escondiéndolo detrás de llamadas a funciones verificadas, y algunos usaban VM. Dejando de lado rendimiento o adopción, las vulnerabilidades principales eran las grietas en la abstracción, los bypass mediante código unsafe, el colapso del modelo de seguridad por culpa del compilador/JIT y fallas comunes de hardware, como rayos cósmicos en naves espaciales. Aun así, siguen siendo mucho más seguros que kernels o apps escritos en lenguajes unsafe. Para ir más allá, se puede usar análisis estático del código unsafe, garantizar que todas las funciones unsafe respeten interfaces type-safe y memory-safe, compiladores que preserven la seguridad de la abstracción durante la integración, e incluso compiladores certificados por componente. La mayoría de las herramientas de productividad ya existen; la única que falta es la "compilación completamente abstraída de forma segura", que hoy está en investigación, aunque también puede verificarse manualmente

    • Hay una razón por la que los sistemas operativos realmente utilizables se pueden contar con los dedos. En el mundo del hardware sobran los "estándares" de interfaz, pero en la práctica casi ningún hardware real se comporta correctamente según el estándar. Si no inviertes tiempo en escribir código de drivers que maneje todo tipo de rarezas y defectos imposibles de corregir (errata), es realmente difícil lograr buen rendimiento y soporte sobre hardware físico real

    • Por otro lado, el 98% de Linux con el que trato corre en entornos virtualizados. En desktop/laptop uso VirtualBox a pantalla completa, solo uso drivers para Windows cuando de verdad hace falta, y en Mac manejo una VM headless administrada por Docker.app. Todas las cargas operativas de la empresa corren en VMs de AWS. El único hardware Linux que uso en casa también es un home server, y pienso reemplazarlo pronto por una VM en un Mac mini comprado en eBay. Si apareciera un kernel compatible con Linux, más seguro y con rendimiento similar, hoy sería fácil elegir una alternativa aunque le faltaran drivers

  • Escuché que últimamente los microkernels han mejorado mucho el problema de rendimiento del IPC. No recuerdo exactamente cuánto mejoraron, pero da la impresión de que el trauma de la industria con Mach fue muy fuerte. Viendo el sitio del proyecto, más bien la estructura parece ser que solo el Framework (modo privilegiado) puede usar unsafe de Rust, mientras que los Services (sin privilegios) usan solo Rust seguro. Se siente raro: si el código sin privilegios usa unsafe, ¿no sigue siendo peligroso aunque no tenga privilegios? En cambio, ¿el código unsafe que realmente necesita validación puede usarse sin límites del lado privilegiado? Y viendo la licencia, Asterinas usa principalmente Mozilla Public License (MPL) 2.0, con algunos componentes bajo licencias más permisivas. No es GPL ni BSD; se siente como algo intermedio

    • Sobre la pregunta de por qué sería raro que "aunque lo no privilegiado use unsafe sigue siendo peligroso, mientras que el código que realmente necesita validación se concentra del lado privilegiado", esto hay que interpretarlo en el contexto de framekernel. Todo el framekernel basado en Rust corre en espacio de kernel, pero lógicamente se divide en dos partes: un framework privilegiado del SO y servicios del SO sin privilegios. La parte privilegiada incluye tanto código de kernel en Rust safe como unsafe; la no privilegiada incluye solo código de kernel en Rust safe. Esta política aplica enteramente a código de kernel. En los framekernels no hay restricciones sobre el lenguaje de los programas de usuario

    • Entiendo que la mayoría de los microkernels recientes han mejorado drásticamente el rendimiento del IPC. Por ejemplo, seL4 optimiza el IPC de forma muy agresiva, al punto de que su IPC es mucho más rápido que una syscall típica de Linux. Es posible que la mayoría de los programas comunes corran incluso más rápido sobre seL4. Me da curiosidad ver datos reales de comparación de rendimiento

    • Sí, los microkernels modernos mejoraron el problema del IPC. En realidad, el problema más de fondo es que en el hardware moderno incluso las syscalls de un kernel monolítico son muy lentas. Por eso interfaces como io_uring o virtio logran buen rendimiento: procesan solicitudes y respuestas en colas entre el sistema y la app (o entre hipervisor y guest), evitando cambios de espacio de direcciones. El sistema operativo del futuro, sea cual sea su estructura, va a necesitar un mecanismo de syscall basado en colas. Y si se adopta ese enfoque, ya no hay tanta diferencia de rendimiento entre dividir el SO como monolítico, microkernel u otra arquitectura

    • En framekernel, la separación privileged/unprivileged no significa kernel/userspace. Todo el SO corre con nivel de privilegio de kernel. Solo que, a nivel lógico, se divide entre código de librería central (privileged, se permite unsafe) y el resto de los componentes del kernel (usan la librería, no pueden usar unsafe directamente, unprivileged). Supongo que eso se hace cumplir con checks estáticos, como un linter. Es una estructura fácil de confundir por la reutilización de términos

    • Como las tareas sin privilegios también corren en el mismo espacio de memoria que el núcleo del kernel, no hay forma de impedir en tiempo de ejecución un comportamiento inseguro. Para separar privilegios de verdad en runtime haría falta una arquitectura de microkernel. Aquí los privilegios se implementan no en runtime sino de forma estática, o sea, prohibiendo el código unsafe

  • Me pregunto si la idea de dividir el kernel en un núcleo pequeño unsafe y módulos grandes safe es realmente un intento nuevo. Me parece interesante y prometedor como proyecto, porque evita el overhead de hardware de un microkernel y también los problemas de seguridad de un monolítico, aprovechando bien la separación safe/unsafe de un lenguaje de sistemas

  • Me hizo pensar en el artículo Rust in Linux revisited de Drew DeVault. También se puede enlazar la discusión en HN https://news.ycombinator.com/item?id=41404733

  • Me parece un intento realmente impresionante, y además me emociona que el autor esté en este hilo. Me pregunto hasta qué punto ya es usable; me gustaría probar a construir una imagen de servidor aunque fuera en algún entorno limitado

    • Asterinas sigue siendo un kernel relativamente nuevo, así que todavía le faltan cosas para uso general. Pero si el objetivo es operar servicios reales de manera eficiente y confiable, la brecha no es tan grande y podría alcanzarse esa meta dentro de un año. En este momento están implementando funciones clave como Linux namespaces y cgroups, además de trabajar en la primera distribución basada en Asterinas. El objetivo inicial es usar Asterinas como guest OS para Confidential VMs, y gracias a su memory safety y su TCB pequeño tiene ventajas claras de seguridad frente a Linux

  • Al ver la explicación de que los microkernels no son populares porque su IPC es lento, me tranquiliza pensar que incluso personas técnicamente brillantes a veces malinterpretan los motivos reales de adopción y cómo se desarrolló todo eso

    • Entonces habría que explicar exactamente en qué se está interpretando mal, para que le sirva a todos

  • La licencia es MPL y, personalmente, creo que hay licencias mejores, como GPLv3

    • En la documentación explican directamente por qué eligieron MPL. No es mi opción favorita, pero la razón me parece entendible

  • Me parece una idea realmente buena. Ya hay muchísimo software construido, y tener una base alternativa puede dar grandes ventajas u opciones incluso por razones no técnicas. Me hace pensar en kFreeBSD y GNU/Hurd

  • Me pregunto cómo habría que llamar a este tipo de kernels. ¿*nux?