Release v1.2.4b: Binding PangeaOS to Live x86-64 Hardware & Surviving Real CPU Crashes

From Simulated Logic to Real Processor Hardware

In earlier versions of PangeaOS, we built and tested our 26 Rust modules using unit tests and simulated fault frames. That proved our state machines were logically sound, but an operating system ultimately has to face real hardware: real processor registers, real interrupt tables, and real CPU exceptions.

In PangeaOS v1.2.4b, we connected our fault-containment engine directly to the x86-64 processor hardware and verified 14 live self-tests on QEMU (-cpu max).

Three Hardware Challenges We Solved in v1.2.4b

1. The 4-Byte Misalignment Trap Inside the 64-Bit TSS

For the processor to automatically switch to an emergency rescue stack (IST 1) when a crash occurs in Ring 0, it reads the stack address from a hardware table called the 64-Bit Task State Segment (TSS). Because the first field of the TSS is a 4-byte integer (reserved0), all the 8-byte stack pointers that follow it sit at memory offsets that are shifted by 4 bytes (0x04, 0x0C, 0x24, etc.). If you define a normal Rust struct, the compiler automatically inserts 4 bytes of invisible padding to align the 8-byte fields—which shifts IST 1 to the wrong address! We solved this by defining TaskStateSegment64 as #[repr(C, packed)] and adding compile-time assertions (assert!(offset_of!(TaskStateSegment64, ist1) == 0x24)) so the layout is guaranteed at build time.

2. Bridging UEFI and Bare-Metal Calling Conventions

When building BOOTX64.EFI for UEFI, the compiler uses the Microsoft x64 calling convention, whereas bare-metal ELF kernels use the System V AMD64 calling convention. If an assembly gate expects arguments in rdi and rsi while the caller passes them in rcx and rdx, the transition will jump to a garbage address. In v1.2.4b, our invoke_domain_live wrapper uses explicit register bindings inside core::arch::asm! (in("di"), in("esi"), in("rdx"), in("rcx"), in("r8d")), making domain transitions 100% immune to compiler ABI differences.

3. Surviving a Live ud2 (#UD) Hardware Crash in Domain 5

During boot self-test #14 ([H2-H4]), PangeaOS enters Service Domain 5 with Domain 5's hardware keycard (PKRU) active and intentionally executes the x86-64 undefined instruction ud2.

• The processor immediately traps through IDT[6] onto IST 1.
• Our assembly stub resets hardware PKRU to 0xCBFF_FFFC (PKRU_KERNEL_DEFAULT), checks the "PANGEAK0" canary, and pivots onto k0_priv_rsp.
• pangea_rust_isr_entry_bridge attributes the crash to Domain 5 (generation 77, vector 6) and jumps via gate_restore_continuation back to the scheduler—completing all 14 boot checks (14/14 OK) and shutting down cleanly.