OptimaOS on Rust: single kernel for all platforms

OptimaOS’s Unified Rust Kernel: Architecture for Desktop, Servers, and Edge

OptimaOS is designed as a unified kernel that powers desktops, servers, Edge devices, and AI accelerators—without forks or recompilation. The project tackles fragmentation head-on: instead of multiple divergent codebases with varying vulnerabilities and APIs, it uses one binary image with dynamic runtime profiles. Core mechanisms are baked into the kernel, while policies are dynamically configured via a policy-service.

By 2026, traditional kernels like Linux, Windows NT, and Darwin will have accumulated significant technical debt. Forks such as Android or embedded Linux require separate security audits and regression testing.

Separation of Mechanisms and Policies

The architecture follows the UNIX principle: the kernel provides mechanisms, while userspace defines policies. This is codified in ADR-0002.

Mechanisms in the kernel (profile-independent):

• Memory management: regions, mmap/munmap/protect.
• Process and thread scheduler.
• IPC bus with typed endpoints.
• Capability graph for resource access.
• Syscall ABI: optima_syscall_v0.

Policies in the runtime profile:

• Process access rules.
• Userspace service configuration (network stack, parameters).
• Scheduler settings (latency vs throughput).
• Allowed syscall patterns.

On boot, the policy file is applied via the runtime API. One binary supports both home (desktop) and server profiles.

Why Rust for Systems Programming?

Rust was chosen for compile-time memory safety without garbage collection. The kernel minimizes the TCB: #[forbid(unsafe_code)] is enforced in kernel-core, with unsafe code restricted to HAL (hardware/mod.rs).

Ownership semantics integrate seamlessly with the capability graph: resources as ownership tokens align with lifetime semantics.

Ecosystem benefits include cargo test, cargo build --target x86_64-unknown-uefi, and robust no_std support—streamlining OS development.

Project Structure

A Rust workspace with crates:

• kernel-core: execution engine.
• linux-compat: Linux ABI bridge (L1/L2).
• policy-service: policy management.
• device-manager: device handling.
• filesystem-service: file systems.
• network-service: networking.
• profile-service: profile overlays.

Services interact with the kernel via typed IPC and capabilities, avoiding direct dependency on kernel-core.

Key Kernel Modules

| Module | Purpose |

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

| runtime.rs | KernelRuntime — lifecycle state machine. |

| syscall.rs | optima_syscall_v0, Kernel structure. |

| ipc.rs | In-memory queue IPC with owner PID. |

| memory.rs | Memory regions, mmap/munmap/protect. |

| scheduler.rs | Scheduler. |

| capability.rs | Capability graph: grant/revoke/transfer. |

| policy.rs | Policy rules and overrides. |

| audit.rs | Audit trail. |

| console_transport.rs | UEFI shim ↔ runtime. |

Console Transport and Boot Process

Two-layer architecture (ADR-0003):

• Stage A (UEFI shim): transport, diagnostics, input/output. Does not execute commands.
• Stage B (kernel-core): entry point for sys.*.

Lifecycle: BootInit → ShimReady → RuntimeAttach → Interactive → Degraded. This separation simplifies verification: UEFI runs in boot mode, runtime operates independently.

Linux ABI Compatibility

linux-compat maps Linux syscalls to optima_syscall_v0 incrementally, minimizing attack surface.

L1 (ready): clone, exit, nanosleep, mmap, sendmsg, recvmsg, basic epoll.

L2-A (ready): fd lifecycle, poll/epoll_wait.

L2-B (ready): signal masks.

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

API is still draft; stability comes later. Each stage undergoes compatibility matrix testing.

Development Roadmap

Priorities:

• Boot on real x86_64 hardware, smoke tests, performance metrics.
• Complete Linux L2, add signalfd/eventfd.
• Android Binder IPC.
• Win32 L3.
• GUI: Unicode, image rendering.

Goal: validate the hypothesis of a single kernel without performance degradation.

Key Takeaways

• One kernel, no forks, serves diverse use cases via runtime profiles.
• Strict separation between kernel mechanisms and userspace policies.
• Rust with #[forbid(unsafe_code)] ensures memory safety in the TCB.
• Incremental Linux ABI support: L1/L2 complete, verified.
• Two-layer Console Transport enables secure boot.

— Editorial Team