OSDev.org

sebihepp wrote: ↑Wed Apr 09, 2025 2:50 am Maybe you missed the stack is growing downwards?
With Limine requests you can request a certain stack size, but AFAIK to get the physical address the only possible solution is to walk the paging manually while the paging from limine is still active.
The error code is 0x3 means the page is not present during a write.

So, if I set all entries in all levels of the PML4 table that I'm manipulating to be writable, kernel execution works ok and there's no page faults after setting CR3. But I didn't think that RW was inherited like that - the whole point of having granularity in our page table setup is to be specific in access control to pages between 4k/2MB/1GB sizes, right? So I don't see why setting all of our RW bits to 0 besides the bottom-level PTE "fixes" things. I believe it to be some other logic error higher up the chain but I haven't been able to nail down what.

vortexian wrote: ↑Wed Apr 09, 2025 2:13 pm So I don't see why setting all of our RW bits to 0 besides the bottom-level PTE "fixes" things. I believe it to be some other logic error higher up the chain but I haven't been able to nail down what.

Ah, found it - AMD64 Volume 2, 5.6.2:

The R/W bit in the page-translation tables specifies the access type allowed for the page. If R/W=0 in
any of the page table entries traversed during a table walk, the page is read-only. If R/W=1 in all the
page table entries traversed during a table walk, the page is read/write.

So I can configure all entries to be RW=1 except for a PTE if needed. Thank you all!!

Thanks for the solution. That's something I could have fallen for too. Now I know it.