Building a Production-Grade 64-Bit x86_64 Microkernel from Scratch: Inside the ARKM Architecture

If you have ever stared at the boot pipeline of a mainstream operating system, you know it carries decades of historical baggage. From legacy 8259 PIC initialization sequences to hardcoded ISA port I/O and BIOS memory maps, writing a modern operating system means fighting ghosts from the 1970s.

Earlier this year, I set out to build ARKM, a clean-room, zero-dependency 64-bit x86_64 microkernel. The goal was simple: take unmediated control of modern silicon (multi-core SMP/AMP topologies, UEFI firmware, PCIe ECAM configuration spaces, NVMe controllers, and RFC-compliant IPv6 stacks) without relying on external source trees or third-party middleware.

This article breaks down how ARKM was engineered from scratch, the hard architectural problems solved along the way, and what it takes to get a custom microkernel production-ready.

1. Bootstrapping into the Modern Era: UEFI and Multiboot2

Traditional kernel tutorials start by assuming a 16-bit real-mode BIOS environment. ARKM completely skips this. It boots via a strict 64-bit Multiboot2 / UEFI handoff governed by a custom assembly stub (boot_uefi.asm) and a production ELF linker script (linker.ld).

Get Aditya “Aadi”’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

When the firmware hands control to the kernel, ARKM establishes a flat 64-bit long-mode environment with identity-mapped page tables (p4_table, p3_table, p2_table) and immediately parses UEFI boot tags.

• Display Handoff: Instead of poking legacy Bochs VBE ports (0x01CE/0x01CF) which break modern displays, ARKM reads the UEFI GOP (Graphics Output Protocol) framebuffer physical address directly from Multiboot2 Tag 8.
• ACPI Discovery: Rather than scanning legacy BIOS memory blind, ARKM parses the UEFI System Table or Multiboot2 ACPI tags to locate the RSDP, traversing ACPI 2.0+ XSDT/RSDT tables to find the MADT (Multiple APIC Description Table).

2. Eradicating Legacy Hardware: APIC, IOAPIC, and MSI

One of the biggest hurdles in kernel development is transitioning away from legacy interrupts. ARKM treats legacy hardware components as deprecated out of the box:

• The 8259A PIC is Dead: The dual 8259 PIC chips are fully initialized through a standard ICW1–ICW4 sequence only to ensure no stray interrupts fire, and then permanently masked (0xFF).
• IOAPIC & MSI Routing: All external hardware interrupts (such as the system timer, PS/2 keyboard, and mouse) are dynamically routed through the system IOAPIC (0xFEC00000) using ACPI Interrupt Source Overrides. High-performance devices like NVMe controllers and Intel E1000 network cards bypass legacy interrupt lines entirely by utilizing Message Signaled Interrupts (MSI) directly mapped to the Local APIC.

3. High-Performance Storage: NVMe Queues and AHCI DMA

Storage access in ARKM is strictly modern. There is no legacy ATA PIO port banging (0x1F0–0x1F7) or ISA Bus Master DMA (0xC040).

[Virtual File System / LUNAFS]
          │
          ▼
┌───────────────────┐     PCIe      ┌──────────────────────┐
│  NVMe Queue Pair  │ ─────────────►│ PCIe NVMe Controller │
└───────────────────┘               └──────────────────────┘
          │ (Fallback)
          ▼
┌───────────────────┐     DMA       ┌──────────────────────┐
│ AHCI SATA Engine  │ ─────────────►│ AHCI SATA Controller │
└───────────────────┘               └──────────────────────┘
          │ (Fallback)
          ▼
┌───────────────────┐
│ Memory RAMDisk    │ (2 MiB Zero-Fault Backup)
└───────────────────┘

• PCIe NVMe Engine: ARKM communicates with NVMe storage through native PCIe admin and I/O submission/completion queue pairs, using doorbell registers and MSI vector 45.
• AHCI SATA FIS DMA: For standard SATA drives, the kernel utilizes FIS-based Direct Memory Access via an AHCI host controller interface, guarded by page-aligned bounce buffers.
• RAMDisk Fallback: If a system lacks physical NVMe or SATA hardware, ARKM falls back to an embedded, memory-backed block layer that pre-seeds a FAT32 filesystem and STATE.BIN file in RAM, ensuring that filesystems like LUNAFS can always mount successfully.

4. Memory Management: O(1) PMM and Aegis W^X

Managing physical memory efficiently is critical for a microkernel. ARKM replaces slow linear bitmap scans with a high-performance allocator:

• Hardware Bit-Scan Optimization: The Physical Memory Manager (PMM) combines a per-CPU magazine cache with a 64-bit word bitmap scanner utilizing __builtin_ctzll (count trailing zeros) and __builtin_popcountll. Instead of checking pages one by one, the kernel scans 64 pages at a time in a single CPU instruction.
• Aegis Security & W^X Enforcement: ARKM enforces strict Write-Exclusive-Xor-Execute (W^X) memory policies. Userspace ELF segments can be writable or executable, but never both. Furthermore, Supervisor Mode Execution Prevention (SMEP) and No-Execute (NX) bits are enabled via MSR 0xC0000080 to prevent malicious kernel-space execution of user-supplied data.

5. Solving the IPv6 Ping Mystery (SLAAC, NDP, and Scope Selection)

Getting an IPv6 stack to talk to a QEMU SLIRP or virtualized network bridge is notoriously tricky. Early builds of ARKM returned IPv6 PING: NO REPLY because of three subtle architectural bugs:

• L2 Source MAC Capture vs. Corrupted Options: The kernel previously misparsed Router Advertisement (RA) options, pulling bogus bytes into router_mac (0x000000FF2ABA17B8). ARKM now strictly captures the router's true L2 MAC directly from the outer Ethernet header (eth->src_mac) and safely decodes EUI-64 router IDs (e.g., converting 0x3E8394FFFEE1260A back to 3C:83:94:E1:26:0A).
• RFC 6724 Source Address Scope Matching: When pinging a Link-Local destination (like the default router at fe80::3e83:94ff:fee1:260a), sending the packet with a Global SLAAC source IP (2405:...) causes the network stack to drop it. ARKM's IPv6 engine now strictly matches address scopes—using Link-Local source IPs for Link-Local destinations and Global source IPs for global routing.
• E1000 Promiscuous Filters: The Intel E1000 driver now explicitly enables both Multicast Promiscuous (MPE) and Unicast Promiscuous (UPE) filters in E1000_REG_RCTRL, ensuring multicast Neighbor Discovery packets and unicast ICMPv6 Echo Replies are never dropped by hardware filters.

6. Native Filesystems and Compositor Graphics

• LUNAFS: ARKM features LUNA, a native extent-based filesystem with atomic generation tracking and strict capability checks, sitting cleanly on top of the raw block layer.
• SIMD-Accelerated Compositor: The graphics engine bypasses heavy user-space display servers like X11 or Wayland. It draws directly to the UEFI GOP linear framebuffer, utilizing PAT Write-Combining (WC) page attributes and 4-KiB page-aliasing at 0xFC000000 to deliver smooth, tearing-free window compositing across multi-core worker threads.

Final Thoughts

Building a microkernel from scratch forces you to confront how much complexity operating systems have accumulated over the decades. By stripping away legacy ISA assumptions and designing cleanly around modern multi-core, UEFI, and IPv6 standards, ARKM proves that a high-performance, secure, and fully native operating environment can be built cleanly, deterministically, and from the metal up.