OptimaOS na Rust: jednolite jądro dla wszystkich platform

Jedno jądro OptimaOS w Rust: architektura dla komputerów stacjonarnych, serwerów i urządzeń Edge

OptimaOS jest tworzony jako jądro obsługujące komputery stacjonarne, serwery, urządzenia Edge oraz akceleratory AI bez potrzeby tworzenia forków czy ponownej kompilacji. Projekt rozwiązuje problem fragmentacji: zamiast wielu oddzielnych gałęzi kodu z różnymi lukami bezpieczeństwa i interfejsami API, używany jest jeden obraz binarny z profilem czasu działania. Jądro zapewnia mechanizmy, a polityki są dynamicznie konfigurowane przez policy-service.

Do 2026 roku tradycyjne jądra — Linux, Windows NT, Darwin — nabrały dużego długu technicznego. Forki takie jak Android czy embedded Linux wymagają osobnych audytów bezpieczeństwa i testów regresyjnych.

Oddzielenie mechanizmów i polityk

Architektura opiera się na zasadzie UNIX: jądro dostarcza mechanizmy, a środowisko użytkownika definiuje polityki. Zasada ta została zapisana w ADR-0002.

Mechanizmy w jądrze (niezależne od profilu):

• Zarządzanie pamięcią: regiony, mmap/munmap/protect.
• Planista procesów i wątków.
• Szyna IPC z typowanymi punktami końcowymi.
• Graf capability do dostępu do zasobów.
• ABI syscall: optima_syscall_v0.

Polityki w profilu czasu działania:

• Zasady dostępu procesów.
• Konfiguracja usług userspace (stos sieciowy, parametry).
• Ustawienia planisty (opóźnienie vs przepustowość).
• Dozwolone wzorce wywołań systemowych.

Podczas uruchamiania plik policy jest stosowany poprzez interfejs runtime. Ten sam plik binarny działa zarówno dla profilu home (komputer stacjonarny), jak i server (serwer).

Zalety Rusta w programowaniu systemowym

Rust został wybrany dzięki bezpieczeństwu pamięci w czasie kompilacji bez GC. Jądro minimalizuje TCB: #[forbid(unsafe_code)] w kernel-core, niebezpieczny kod tylko w HAL (hardware/mod.rs).

Model ownership jest zintegrowany z grafem capability: zasoby jako tokeny własności odpowiadają semantyce życia.

Ekosystem: cargo test, cargo build --target x86_64-unknown-uefi, wsparcie no_std ułatwiają rozwój systemów operacyjnych.

Struktura projektu

Przestrzeń workspace w Rust z crate’ami:

• kernel-core: silnik wykonawczy.
• linux-compat: most do ABI Linuxa (L1/L2).
• policy-service: zarządzanie politykami.
• device-manager: zarządzanie urządzeniami.
• filesystem-service: systemy plików.
• network-service: sieć.
• profile-service: overlay profili.

Usługi komunikują się z jądrem przez typowaną IPC i capability, bez bezpośredniej zależności od kernel-core.

Kluczowe moduły jądra

| Moduł | Zadanie |

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

| runtime.rs | KernelRuntime — maszyna stanów cyklu życia.

| syscall.rs | optima_syscall_v0, struktura Kernel.

| ipc.rs | IPC w pamięci operacyjnej z właścicielem PID.

| memory.rs | Regiony pamięci, mmap/munmap/protect.

| scheduler.rs | Planista.

| capability.rs | Graf capability: grant/revoke/transfer.

| policy.rs | Zasady i nadpisywanie polityk.

| audit.rs | Ślad audytowy.

| console_transport.rs | Shim UEFI ↔ runtime.

Transport konsoli i uruchamianie

Architektura dwuwarstwowa (ADR-0003):

• Etap A (shim UEFI): transport, diagnostyka, wejście/wyjście. Nie wykonuje poleceń.
• Etap B (kernel-core): punkt wykonania sys.*.

Cykl życia: BootInit → ShimReady → RuntimeAttach → Interactive → Degraded. Oddzielenie upraszcza weryfikację: UEFI w trybie boot, runtime osobno.

Zgodność z ABI Linuxa

linux-compat mapuje wywołania systemowe Linuxa na optima_syscall_v0 etapowo, minimalizując powierzchnię ataku.

L1 (gotowe): clone, exit, nanosleep, mmap, sendmsg, recvmsg, podstawowy epoll.

L2-A (gotowe): cykl życia deskryptora, poll/epoll_wait.

L2-B (gotowe): maski sygnałów.

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

API to szkic, stabilność później. Każdy etap jest weryfikowany testami matrix compatibility.

Plan rozwoju

Priorytety:

• Uruchomienie na rzeczywistym x86_64, testy smoke, metryki wydajności.
• Zakończenie L2 Linuxa, dodanie signalfd/eventfd.
• IPC Binder dla Androida.
• Win32 L3.
• GUI: Unicode, renderowanie obrazów.

Cel: potwierdzić hipotezę jednego jądra bez utraty wydajności.

Co jest ważne

• Jedno jądro bez forków obsługuje różne scenariusze przez profile czasu działania.
• Silne oddzielenie mechanizmów (jądro) i polityk (userspace).
• Rust z #[forbid(unsafe_code)] gwarantuje bezpieczeństwo pamięci w TCB.
• Etapowa zgodność z ABI Linuxa: L1/L2 gotowe, z weryfikacją.
• Dwuwarstwowy transport konsoli dla bezpiecznego uruchamiania.

— Editorial Team