§ 01
Why an Operating System Should Not Panic When a Single Service Fails
Moving From 'Halt on Any Error' to Isolating Broken Services While Keeping the Computer Running
PangeaOS is a 64-bit operating system written from scratch in Rust. Instead of locking every program inside a separate virtual memory map and wasting processor time switching between them, PangeaOS places the kernel, drivers, and services inside one shared address space—while using hardware memory keys and dedicated rescue stacks so that a crash in one service never freezes the whole computer.
Every time you use a computer, dozens of background programs—network drivers, file systems, device managers, and applications—are constantly passing data back and forth. The operating system is responsible for making sure these programs can communicate quickly while preventing a bug in one program from corrupting another.
Traditionally, operating systems have had to choose between two extremes: build thick walls between every program (which is safe, but slow to cross), or remove the walls entirely (which is fast, but means a single bug can bring down the entire computer). Let us look at how these approaches compare.
Mainstream operating systems give every running program its own separate virtual memory map. You can think of this like placing every worker in a separate locked building across town. If one program crashes, the damage stays inside its own building. However, whenever Program A wants to send a message to Program B—or ask the operating system kernel to read a file—the processor has to stop, change hardware privilege modes, load a brand-new address map, and clear its internal lookup caches. The safety is strong, but the processor spends a significant amount of time just traveling between buildings.
To eliminate switching delays, some experimental operating systems place the kernel, device drivers, and services inside one shared memory space at the processor's highest privilege level. Because everyone is in the same room using the same address map, passing data is as fast as a normal function call. The problem is that there are no locks between desks: a stray pointer in one buggy driver can overwrite the core operating system's memory. Worse, when any unexpected error happens, the operating system cannot tell whether shared memory was damaged, so it has to call panic!() and halt the entire machine.
PangeaOS keeps all components on the same shared floor so the processor never wastes time swapping address maps. To keep programs from interfering with each other, PangeaOS inspects every program's machine code before launch and locks each service inside its own 1-Terabyte workspace using a hardware feature called Memory Protection Keys. Most importantly, if a single service crashes, hits an invalid instruction, or gets stuck in an endless loop, PangeaOS does not shut down the computer. The processor jumps to an independent emergency rescue stack, locks out only the broken service, and lets all other services continue working.
How does PangeaOS isolate programs and recover from crashes when everything lives in the same address space? It relies on four mechanisms working together:
Before any service is allowed to start, PangeaOS scans its compiled machine instructions from start to finish. If a binary contains any instruction that could disable interrupts, alter processor tables, or change memory keys—or if it tries to access memory outside its assigned 1-Terabyte window—it is rejected before execution begins.
Modern x86-64 processors allow every memory page to be tagged with one of 16 keys (K0 to K15). Key K0 belongs to the core kernel, and Keys K1–K12 belong to twelve isolated services. While Service 3 is running, only Key 3 is unlocked for writing; the kernel and all other services remain locked by the CPU hardware.
When a service crashes, its own stack might be corrupted. PangeaOS wires the CPU's interrupt table to an independent emergency rescue stack (IST 1). On any fault, the CPU switches to the rescue stack, restores the kernel's master keycard, records which service failed, and jumps back to the main scheduler bookmark.
A hardware timer ticks every 1 millisecond to prevent any service from hogging the processor in an infinite loop. Each service also has strict caps on memory and message queues, while 16 Megabytes of RAM are permanently reserved for the core kernel so recovery operations never run out of memory.
Read our dedicated Core Concepts Guide or browse the 30+ Term Glossary & FAQ.
We recommend starting with 01. Core Concepts and 02. Glossary & FAQ for a thorough foundation, then exploring the architectural report, blueprint, specification, and code walkthrough.
A detailed, illustrated guide explaining virtual memory, privilege rings, why context switches are slow, and how PangeaOS's seven safety layers and emergency rescue stacks work from boot to recovery.
Clear, multi-paragraph explanations of every technical term used in PangeaOS—from Ring 0, SASOS, and MPK/PKRU to IST stacks, PFN databases, Double-Fetch prevention, and IOMMU isolation—plus answers to common questions.
Examines why halting the system on every error turns minor bugs into Denial-of-Service outages, how PangeaOS classifies local faults (L0–L3) vs. fatal faults (F1–F3), and our engineering trade-offs.
Explains the role of every single Rust crate in the repository, why 16 crates forbid unsafe code entirely, how linker scripts isolate assembly gates, and what each milestone (M0–M8 & H0–H4) verifies.
The complete technical rulebook: the 48-bit virtual memory map, 1-Terabyte domain sandboxes, exact PKRU bitmasks, 64-bit GDT and packed 104-byte TSS layout, and Dual-Class IPC rules.
Presents real #![no_std] Rust and x86-64 assembly code from PangeaOS v1.2.4b with thorough explanations before and after each block so you can see how the concepts are implemented.
Moving From 'Halt on Any Error' to Isolating Broken Services While Keeping the Computer Running
Why Hardware Keys Need Code Scanning to Guard the Keycard Register, and Why Code Scanning Needs Hardware Keys to Police Runtime Pointers
How PangeaOS v1.2.4b Loads Its Own Hardware Descriptor Tables and Survives a Live Invalid-Instruction Crash Without Rebooting