DeanoBurrito / northport

Monolithic kernel and support libraries for riscv64 and x86_64.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Kernel page tables can fall out of sync

DeanoBurrito opened this issue · comments

commented

Currently: all pages table are cloned from the kernel pages, and the bottom half is used for programs. If kernel code modifies memory in any of the layers except the top, this is fine, as these are shared structures.
However if paging data is modified the lop level of the structure (pml4, or pml5 is la57 is enabled) this wont be updated on other kernel pagetables (on other processes).

One solution is to simply map the entire higher half of the top level table, and then level the page faults occur at top_level - 1. This would use slightly more initial memory as the top_level - 1 pages would need to be allocated (~1MB of memory reserved for these). This is a one time cost, as these pages would be referenced by all top level paging structures. No extra memory cost would occur for cloned tables, as a full top level table is required anyway, and would simply point to these already created structures.

commented

Now that I think about it, each pml4 entry controls access to a 512GB region of memory, its extremely unlikely that we cross these boundaries during runtime.
Assuming physical memory does not change size, the largest mapped area (hhdm) is static, and the kernel heap is allocated above the kernel, so that will always be within the same 2GB region as the kernel.
We are more likely to run out of heap space before we fall out of sync, closing this issue based on that.