Creating an x86_64 kernel in Rust: Part 4

2026-08-10T16:00:00+00:00

The frame allocator from Part 3 hands out physical frames, but the kernel can't touch one until something maps it to a virtual address. That mapping is the last piece missing before alloc</code> works, so by the end of this part Vec</code>, Box</code> and String</code> all do something useful.</p>

Writing an OS in Rust</a> covers this ground too, in Paging Implementation</a> and Heap Allocation</a>, and it's the thing to read if you want an allocator written from scratch. This part is on limine and its higher half mapping instead of the bootloader</code> crate, and I grab a heap allocator from crates.io instead of writing one, which is a whole other post.</p>

Pinned to limine</code> 0.6.5, x86_64</code> 0.15.5 and buddy_system_allocator</code> 0.13 on nightly. The x86_64</code> version matters: anything older than 0.15.5 doesn't build on a current nightly.</p>

Finding the level 4 table</h2>
Page tables live at physical addresses. The kernel can only dereference virtual ones. The higher half offset from Part 3 gets us around that: limine already mapped every usable physical page at that offset, so adding it to a physical address gives us something we can actually read.</p>
CR3</code> holds the physical frame of the level 4 table:</p>

// memory/mapper.rs</span></span>
</span>
/// Borrow the active level 4 page table.</span></span>
///</span></span>
/// # Safety</span></span>
///</span></span>
/// The caller must pass limine's higher half offset, and must not make a second</span></span>
/// live borrow of the table.</span></span>
pub unsafe fn</span> active_level_4_table</span>(physical_memory_offset</span>:</span> VirtAddr</span>)</span> -> &</span>'</span>static</span> mut</span> PageTable</span> {</span></span>
    // CR3 holds the physical frame of the level 4 table.</span></span>
    let</span> (level_4_table_frame, _)</span> =</span> Cr3</span>::</span>read</span>();</span></span>
</span>
    let</span> phys</span> =</span> level_4_table_frame</span>.</span>start_address</span>();</span></span>
    // The only way to reach it: limine already mapped all physical memory here.</span></span>
    let</span> virt</span> =</span> physical_memory_offset</span> +</span> phys</span>.</span>as_u64</span>();</span></span>
    let</span> page_table_ptr</span>: *</span>mut</span> PageTable</span> =</span> virt</span>.</span>as_mut_ptr</span>();</span></span>
</span>
    unsafe</span> {</span> &</span>mut</span> *</span>page_table_ptr }</span></span>
}</span></span></code></pre>
That &'static mut</code> isn't really true. Nothing stops a second caller from making another one, and then you have two aliasing mutable references to the same table. We call it once during boot and put the result behind a lock, which is what the next section does. That stops being enough once there's more than one CPU, and that's a later part.</p>
The mapper</h2>
Because limine maps all of physical memory at a fixed offset, translating a physical address to a virtual one is addition. The x86_64</code> crate has a type for exactly that case, OffsetPageTable</code></a>, so we don't have to walk the tables by hand.</p>

Edgar Luque

Creating an x86_64 kernel in Rust: Part 4

`The mapper</h2>Because limine maps all of physical memory at a fixed offset, translating a physical address to a virtual one is addition. The x86_64</code> crate has a type for exactly that case, OffsetPageTable</code></a>, so we don't have to walk the tables by hand.</p>`