Sterling OS

Minimal Capability-Based Operating System

Design Principles

• No global filesystem, no path resolution
• No drivers in kernel, only sandboxed userspace driver processes
• No GPU acceleration, all rendering is deterministic software-based
• All resources accessed via capability tokens
• Processes are strictly sandboxed
• Programs operate on memory buffers, not raw file handles
• Desktop environment is a sandboxed coordinator, not a privileged process

Authorization Token Model

Programs delegate access via opaque, kernel-managed tokens.

		grant_token(target_pid, resource_id, flags) -> token_id
		accept_token(token_id) -> resource_handle
		revoke_token(token_id)
		

File Editing Flow

1. DE requests file via storage service
2. Storage service provides a memory buffer
3. Editor process receives buffer handle, edits
4. Changes submitted back to storage via DE

Driver Model

• All drivers run as fully unprivileged user processes
• No driver registration or kernel mediation required
• Drivers communicate with hardware via explicit kernel-exposed capability channels
• No dynamic linking or privileged probing allowed
• Users can run or replace any driver without OS permission

Graphics System

• No GPU support, no shaders
• Software renderer processes draw via shared memory
• DE composites framebuffers deterministically

Programming Language Requirements

• Manual memory management
• Low-level data layout control
• Inline assembly support
• Pattern matching and compile-time macros
• No runtime, no global init, no dynamic linking

Execution Model

• Programs are spawned with exact buffer and token permissions
• No shared global state
• All IO is mediated via explicit capability-based services
• Everything is inspectable and reproducible

Sandboxing Model

All processes are isolated via strict memory boundaries and capability-scoped access. No process can access global state, shared memory, or system calls without explicit capability grants.

Memory Layout

		+-----------------------+
		| Code (RX)             |
		+-----------------------+
		| Data (RW)             |
		+-----------------------+
		| Shared Buffers (RWX?) | ← only if explicitly mapped by kernel
		+-----------------------+
		| Stack (RW)            |
		+-----------------------+
		

Process Launch

• Preallocated memory map (no heap growth)
• Passed a syscall pointer table, token list, and init buffer
• Cannot request global system resources directly

Capability Enforcement

All access is mediated via capability tokens, handed off securely:

		token_id = request_token(pid, SERVICE_IO, READ_WRITE);
		handle = accept_token(token_id);
		

• Token scope, rights, and duration enforced by kernel
• No access without explicit grant
• All capability use is auditable and revocable

Filesystem Abstraction

• No global file system
• Programs receive only memory buffers with scoped access
• Read/write must go through kernel-mapped tokens

Driver Isolation

• Drivers are userland processes only
• No direct port I/O or DMA access
• Hardware is accessed via kernel-exposed capability channels

IPC

• All inter-process communication is routed via the kernel
• Uses named ports and token-authenticated message queues
• No shared memory by default

Future Additions

• Deterministic scheduler
• Audit trail of all token activity
• Formal capability typing system

Philosophy

Not a POSIX clone. It is a deterministic, capability-secure, user-controlled computing environment built to reject legacy complexity and embrace verifiable simplicity.