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

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