Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

The Sensitivity Classification Principle

At the heart of the framekernel architecture is a systematic classification of OS resources. An OS manages three fundamental classes of resources — CPU, memory, and devices — each subdivided into sensitive (can compromise kernel memory safety if misused) and insensitive (cannot compromise kernel memory safety even if misused). To ensure the soundness and minimality of TCB, OSTD adopts the following design principle:

Keep sensitive resources inside the framework (for soundness) and move insensitive resources outside (for minimality).

CPU Resources

ResourceClassificationRationaleOSTD Handling
Kernel-mode registers (CR0–CR4, MSRs, GDT/IDT/TSS pointers, kernel GS base)SensitiveCan corrupt execution environmentSet once at boot; never exposed to clients
Kernel-mode traps (exception/interrupt handlers)SensitiveCan hijack control flowIDT configured at boot; handlers are internal
User-mode registers (GP registers, user RFLAGS subset, FS base)InsensitiveCannot directly affect kernel stateExposed via UserContext with sanitization
User-mode trapsInsensitiveRouted through kernel trap handlerDispatched by OSTD; clients handle via callbacks

UserContext sanitizes user-visible registers: it forces the IF (Interrupt Flag) and ID flags in RFLAGS and strips IOPL, preventing user space from disabling interrupts or accessing I/O ports directly. Kernel-mode registers are never represented in any client-visible type.

Memory Resources

ResourceClassificationRationaleOSTD Handling
Kernel code pagesSensitiveOverwriting code = arbitrary executionMapped read-only; typed frames; never exposed
Kernel stack pagesSensitiveStack corruption = control flow hijackTyped frames; guard pages; never exposed
Kernel heap pagesSensitiveHeap corruption = type confusionTyped frames (SlabMeta); never exposed
Page table pagesSensitivePT corruption = arbitrary memory accessTyped frames (PageTablePageMeta); managed by OSTD
Frame metadata pagesSensitiveMetadata corruption = use-after-freeIn dedicated FRAME_METADATA_RANGE; never exposed
User-space virtual memoryInsensitiveKernel safety does not depend on itManipulated safely via VmSpace
Untyped physical memory pagesInsensitiveDo not host Rust objects; accessed only via POD copyExposed as UFrame / USegment; used for user pages, DMA buffers

The sensitive/insensitive distinction maps directly to the typed/untyped frame distinction (Safe Physical Memory Management). All sensitive memory is held in typed frames, which are never exposed to clients, user space, or devices. All insensitive memory is held in untyped frames, which can be safely shared.

Device Resources

ResourceClassificationRationaleOSTD Handling
Local APICSensitiveCan reset CPUs, mask interruptsIoMem<Sensitive>, pub(crate) only
I/O APICSensitiveCan redirect interruptsIoMem<Sensitive>, pub(crate) only
IOMMUSensitiveControls DMA accessIoMem<Sensitive>, pub(crate) only
PIC (8259A)SensitiveLegacy interrupt controllerSensitive I/O ports, pub(crate) only
Peripheral MMIO (NIC, disk, USB, GPU)InsensitiveFailure confined to the deviceIoMem<Insensitive> via IoMem::acquire(range)
Peripheral I/O portsInsensitiveFailure confined to the deviceIoPort via IoPort::acquire(port)
Peripheral interruptsInsensitiveRouted through OSTD’s IRQ frameworkIrqLine callback registration
DMA mappingsInsensitiveRestricted by IOMMU to untyped memoryDmaCoherent / DmaStream APIs

Internally, OSTD maintains two I/O resource allocators (IoMemAllocator, IoPortAllocator) that are initialized at boot time by removing all sensitive ranges. Only the remaining insensitive ranges are available for client allocation. This makes it impossible for a client to accidentally or maliciously access a sensitive device.