OptimaOS en Rust: núcleo único para todas las plataformas

El núcleo unificado de Rust de OptimaOS: arquitectura para escritorio, servidores y edge

OptimaOS está diseñado como un núcleo único que impulsa escritorios, servidores, dispositivos edge y aceleradores de IA—sin bifurcaciones ni recompilaciones. El proyecto enfrenta directamente la fragmentación: en lugar de múltiples bases de código divergentes con vulnerabilidades y APIs distintas, utiliza una única imagen binaria con perfiles de tiempo de ejecución dinámicos. Los mecanismos centrales están integrados en el núcleo, mientras que las políticas se configuran dinámicamente mediante un servicio de políticas.

Para 2026, núcleos tradicionales como Linux, Windows NT y Darwin habrán acumulado una deuda técnica significativa. Bifurcaciones como Android o Linux embebido requieren auditorías de seguridad y pruebas de regresión separadas.

Separación entre mecanismos y políticas

La arquitectura sigue el principio UNIX: el núcleo proporciona mecanismos, mientras que el espacio de usuario define políticas. Esto se codifica en el ADR-0002.

Mecanismos en el núcleo (independientes del perfil):

• Gestión de memoria: regiones, mmap/munmap/protect.
• Planificador de procesos y hilos.
• Bus de IPC con puntos finales tipados.
• Grafo de capacidades para acceso a recursos.
• ABI de sistema: optima_syscall_v0.

Políticas en el perfil de tiempo de ejecución:

• Reglas de acceso a procesos.
• Configuración de servicios de espacio de usuario (pila de red, parámetros).
• Configuración del planificador (latencia frente a rendimiento).
• Patrones permitidos de llamadas al sistema.

Al arranque, el archivo de política se aplica mediante la API de tiempo de ejecución. Un solo binario soporta tanto el perfil home (escritorio) como el server.

¿Por qué Rust para programación de sistemas?

Rust fue elegido por su seguridad de memoria en tiempo de compilación sin recolección de basura. El núcleo minimiza el TCB: #[forbid(unsafe_code)] se aplica en kernel-core, con código inseguro restringido al HAL (hardware/mod.rs).

Las semánticas de propiedad se integran sin esfuerzo con el grafo de capacidades: los recursos como tokens de propiedad se alinean con las semánticas de vida útil.

Los beneficios del ecosistema incluyen cargo test, cargo build --target x86_64-unknown-uefi y soporte robusto para no_std, lo que agiliza el desarrollo de sistemas operativos.

Estructura del proyecto

Un workspace de Rust con crates:

• kernel-core: motor de ejecución.
• linux-compat: puente de ABI de Linux (L1/L2).
• policy-service: gestión de políticas.
• device-manager: manejo de dispositivos.
• filesystem-service: sistemas de archivos.
• network-service: redes.
• profile-service: superposiciones de perfiles.

Los servicios interactúan con el núcleo mediante IPC tipado y capacidades, evitando dependencias directas de kernel-core.

Módulos clave del núcleo

| Módulo | Propósito |

|--------|---------|

| runtime.rs | KernelRuntime — máquina de estados del ciclo de vida. |

| syscall.rs | optima_syscall_v0, estructura Kernel. |

| ipc.rs | IPC con colas en memoria, PID propietario. |

| memory.rs | Regiones de memoria, mmap/munmap/protect. |

| scheduler.rs | Planificador. |

| capability.rs | Grafo de capacidades: otorgar/revoke/transferir. |

| policy.rs | Reglas y anulaciones de políticas. |

| audit.rs | Registro de auditoría. |

| console_transport.rs | Adaptador UEFI ↔ runtime. |

Transporte de consola y proceso de arranque

Arquitectura de dos capas (ADR-0003):

• Etapa A (shim UEFI): transporte, diagnóstico, entrada/salida. No ejecuta comandos.
• Etapa B (kernel-core): punto de entrada para sys.*.

Ciclo de vida: BootInit → ShimReady → RuntimeAttach → Interactive → Degraded. Esta separación simplifica la verificación: UEFI funciona en modo de arranque, el runtime opera de forma independiente.

Compatibilidad con ABI de Linux

linux-compat mapea llamadas al sistema de Linux a optima_syscall_v0 de forma incremental, minimizando la superficie de ataque.

L1 (listo): clone, exit, nanosleep, mmap, sendmsg, recvmsg, epoll básico.

L2-A (listo): ciclo de vida de descriptores, poll/epoll_wait.

L2-B (listo): máscaras de señales.

L2-C (listo): epoll_ctl(DEL/MOD).

La API aún está en borrador; la estabilidad llegará después. Cada etapa pasa por pruebas de matriz de compatibilidad.

Hoja de ruta de desarrollo

Prioridades:

• Arranque en hardware real x86_64, pruebas de humo, métricas de rendimiento.
• Completar Linux L2, añadir signalfd/eventfd.
• IPC Android Binder.
• Win32 L3.
• GUI: Unicode, renderizado de imágenes.

Objetivo: validar la hipótesis de un único núcleo sin degradación de rendimiento.

Conclusiones clave

• Un solo núcleo, sin bifurcaciones, sirve para múltiples casos de uso mediante perfiles de tiempo de ejecución.
• Separación estricta entre mecanismos del núcleo y políticas de espacio de usuario.
• Rust con #[forbid(unsafe_code)] garantiza seguridad de memoria en el TCB.
• Soporte incremental para ABI de Linux: L1/L2 completos y verificados.
• Transporte de consola de dos capas permite arranque seguro.

— Editorial Team