Rust 기반 OptimaOS: 모든 플랫폼을 위한 단일 커널

옵티마OS의 통합 루스트 커널: 데스크톱, 서버, 엣지까지 아우르는 아키텍처

옵티마OS는 데스크톱, 서버, 엣지 디바이스, AI 가속기까지 하나의 커널로 구동하는 통합 시스템입니다. 코드 분기나 재컴파일 없이도 다양한 환경을 지원합니다. 이 프로젝트는 기존의 분산된 코드베이스 문제를 직접 해결합니다. 여러 가지 다른 보안 취약점과 API를 가진 별개의 커널 대신, 하나의 바이너리 이미지와 동적 런타임 프로파일을 활용합니다. 핵심 메커니즘은 커널 내부에 고정되어 있으며, 정책은 정책 서비스를 통해 실시간으로 설정됩니다.

2026년까지 기존 커널인 리눅스, 윈도우 NT, 다르윈은 막대한 기술 부채를 축적하게 됩니다. 안드로이드나 임베디드 리눅스처럼 분기된 버전은 각각 별도의 보안 감사와 회귀 테스트가 필요합니다.

메커니즘과 정책의 분리

아키텍처는 유닉스 원칙을 따릅니다: 커널은 메커니즘을 제공하고, 사용자 공간에서 정책을 정의합니다. 이는 ADR-0002 문서에 명시되어 있습니다.

커널 내부의 메커니즘 (프로파일 독립):

• 메모리 관리: 영역, mmap/munmap/protect
• 프로세스 및 스레드 스케줄러
• 타입화된 엔드포인트를 갖춘 IPC 버스
• 자원 접근을 위한 캡슐리티 그래프
• 시스템콜 ABI: optima_syscall_v0

런타임 프로파일에서 정의되는 정책:

• 프로세스 접근 규칙
• 사용자 공간 서비스 구성 (네트워크 스택, 파라미터)
• 스케줄러 설정 (지연 시간 vs 처리량)
• 허용되는 시스템콜 패턴

부팅 시, 정책 파일은 런타임 API를 통해 적용됩니다. 하나의 바이너리로 home (데스크톱)과 server 프로파일 모두를 지원합니다.

시스템 프로그래밍에 루스트를 선택한 이유

루스트는 가비지 컬렉션 없이 컴파일 타임 메모리 안전성을 제공하기 때문에 선택되었습니다. 커널은 TCB(신뢰할 수 있는 계층)를 최소화하며, kernel-core에서는 #[forbid(unsafe_code)]가 강제 적용되며, 불안전 코드는 하드웨어 추상화 계층(HAL)인 hardware/mod.rs에 한정됩니다.

소유권 개념은 캡슐리티 그래프와 자연스럽게 통합됩니다. 리소스를 소유권 토큰으로 다루는 방식은 수명 주기와 일치합니다.

생태계 혜택으로는 cargo test, cargo build --target x86_64-unknown-uefi, 그리고 견고한 no_std 지원이 있으며, 운영체제 개발을 크게 단순화합니다.

프로젝트 구조

루스트 워크스페이스에 다음과 같은 크레이트 포함:

• kernel-core: 실행 엔진
• linux-compat: 리눅스 ABI 브리지 (L1/L2)
• policy-service: 정책 관리
• device-manager: 장치 처리
• filesystem-service: 파일 시스템
• network-service: 네트워킹
• profile-service: 프로파일 오버레이

서비스들은 타입화된 IPC와 캡슐리티를 통해 커널과 상호작용하며, kernel-core에 직접 의존하지 않습니다.

핵심 커널 모듈

| 모듈 | 목적 |

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

| runtime.rs | KernelRuntime — 생명주기 상태 머신 |

| syscall.rs | optima_syscall_v0, Kernel 구조체 |

| ipc.rs | 소유자 PID를 갖는 메모리 내 큐 기반 IPC |

| memory.rs | 메모리 영역, mmap/munmap/protect |

| scheduler.rs | 스케줄러 |

| capability.rs | 캡슐리티 그래프: 부여/취소/이전 |

| policy.rs | 정책 규칙 및 오버라이드 |

| audit.rs | 감사 트레일 |

| console_transport.rs | UEFI 쉘 ↔ 런타임 |

콘솔 전송과 부팅 과정

두 계층 아키텍처 (ADR-0003):

• 단계 A (UEFI 쉘): 전송, 진단, 입력/출력. 명령 실행 불가.
• 단계 B (kernel-core): sys.*의 진입점.

생명주기: BootInit → ShimReady → RuntimeAttach → Interactive → Degraded. 이 분리는 검증을 간소화합니다. UEFI는 부팅 모드에서 작동하고, 런타임은 독립적으로 운영됩니다.

리눅스 ABI 호환성

linux-compat는 리눅스 시스템콜을 optima_syscall_v0로 점진적으로 매핑하여 공격 범위를 최소화합니다.

L1 (준비 완료): clone, exit, nanosleep, mmap, sendmsg, recvmsg, 기본 epoll

L2-A (준비 완료): fd 수명 주기, poll/epoll_wait

L2-B (준비 완료): 신호 마스크

L2-C (준비 완료): epoll_ctl(DEL/MOD)

API는 여전히 초안 상태이며, 안정성은 이후에 확보됩니다. 각 단계는 호환성 매트릭스 테스트를 거칩니다.

개발 로드맵

우선순위:

• 실제 x86_64 하드웨어에서 부팅, 스모크 테스트, 성능 지표 수집
• 리눅스 L2 완료, signalfd/eventfd 추가
• 안드로이드 바인더 IPC
• 윈도우32 L3
• GUI: 유니코드, 이미지 렌더링

목표: 단일 커널이 성능 저하 없이 다양한 사용 사례를 지원한다는 가설을 검증하는 것.

핵심 요약

• 하나의 커널, 분기 없이 데스크톱, 서버, 엣지 등 다양한 환경을 런타임 프로파일로 지원.
• 커널 메커니즘과 사용자 공간 정책 사이의 엄격한 분리.
• #[forbid(unsafe_code)]를 활용한 루스트로 TCB 내 메모리 안전 보장.
• 점진적인 리눅스 ABI 지원: L1/L2 완료, 검증 완료.
• 두 계층 콘솔 전송을 통한 안전한 부팅 구현.

— Editorial Team