Maestro: un kernel compatible con Linux en Rust

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo sistema operativo de hobby llamado Maestro busca reimplementar un kernel compatible con Linux en Rust, lo que ha desatado debates sobre hasta dónde puede llegar la compatibilidad a nivel de llamadas al sistema sin el enorme ecosistema de controladores y las ABI inestables dentro del kernel de las que depende Linux. Los comentaristas sopesan las posibles ganancias de seguridad de un kernel en su mayor parte seguro en memoria —especialmente para el aislamiento de contenedores— frente a la realidad de que los kernels todavía necesitan mucho código `unsafe`, pueden sufrir errores lógicos y deben interactuar con hardware y firmware inseguros. El proyecto también reaviva discusiones de larga data sobre diseños monolíticos frente a microkernels y sobre copyleft al estilo GPL frente a licencias permisivas, y muchos ven valor en kernels experimentales en Rust pero dudan de que sustituyan a Linux en el corto plazo.

Alcance y objetivos del proyecto

  • Maestro es un SO de hobby que comenzó como una tarea escolar: un kernel monolítico de 32 bits, compatible con las llamadas al sistema de Linux, escrito en Rust.
  • El objetivo es principalmente educativo; cualquier adopción externa es una ventaja.
  • Actualmente implementa aproximadamente un tercio de las llamadas al sistema de Linux, pero arranca lo suficiente como para ejecutar bash y está cerca de poder ejecutar herramientas como vim y compiladores.
  • Usa controladores de hardware clásicos (VGA, PS/2, IDE/ATA); algunos comentaristas sugieren apuntar a VMs y virtio como un siguiente paso práctico.
  • La compatibilidad completa con aplicaciones de Linux se ve como algo de años, principalmente debido a llamadas al sistema complejas, la pila TTY y el enorme ecosistema de controladores.

Rust, seguridad de memoria y seguridad

  • Muchos ven un kernel en Rust como una gran reducción de riesgo: menos errores de memoria, mejor aislamiento de las regiones unsafe y explotación más कठिनa (se usan anécdotas de intentos de explotar Rust como apoyo).
  • Otros enfatizan “más seguro en memoria”, no “seguro en memoria”: el kernel y los controladores todavía necesitan unsafe, y los errores lógicos, la mala configuración, los problemas de hardware y el firmware siguen siendo vectores de ataque importantes.
  • Debate en torno a los contenedores: algunos sostienen que los errores de memoria del kernel son la razón principal por la que los contenedores no pueden ser un límite fuerte; otros dicen que la mayoría de las fugas reales de contenedores provienen de errores de configuración y de la superficie más amplia del kernel, no solo de errores de memoria.
  • Se discuten los microkernels (p. ej., seL4) y la verificación formal como vías alternativas o complementarias para obtener garantías más fuertes.

Controladores, estabilidad del ABI y reutilización

  • Hay consenso en que los controladores son la parte más difícil del trabajo en sistemas operativos.
  • El ABI de espacio de usuario de Linux es muy estable; su ABI de controladores en el kernel es deliberadamente inestable para facilitar la evolución interna y desalentar controladores cerrados, lo que hace irrealista la compatibilidad de módulos entre kernels.
  • Sugerencias para Maestro: centrarse en un conjunto pequeño de hardware o en VMs, reutilizar mediante rump kernels, o incluso ejecutar Linux en una VM para los controladores que faltan.

Debates de arquitectura y diseño

  • Algunos desearían que Maestro apostara por un microkernel o una arquitectura más radical; otros señalan que combinar “Rust + compatibilidad con Linux” ya supone suficiente experimentación.
  • Un gran subhilo debate sobre escribir kernels en ensamblador RISC-V para evitar la “complejidad” del lenguaje/compilador; la mayoría de los participantes lo considera poco práctico, inmantenible y no significativamente más seguro ni más portable.

Debates sobre licencias

  • Maestro está licenciado bajo MIT.
  • Un sector advierte que esto invita a bifurcaciones propietarias y a “hacer trabajo gratis para futuras corporaciones”, argumentando que la GPL (o la AGPL) preserva mejor las libertades de los usuarios y ayudó a que Linux tuviera éxito.
  • Otros responden que las licencias permisivas también permiten ecosistemas comunitarios vibrantes, que la GPL no garantiza un buen comportamiento y que los usuarios no pierden nada si coexisten bifurcaciones propietarias con el original.
  • Algunos sugieren igualar la GPLv2 de Linux para facilitar el intercambio de código y evitar debates interminables sobre licencias.