[HN Gopher] Self-referencing Page Tables for the x86-Architecture
___________________________________________________________________
Self-referencing Page Tables for the x86-Architecture
Author : stv0g
Score : 56 points
Date : 2025-12-25 08:58 UTC (14 hours ago)
(HTM) web link (0l.de)
(TXT) w3m dump (0l.de)
| cmpxchg8b wrote:
| I'm confused, is this meant to be presented as new work? Windows
| has done this for a very long time.
| protoman3000 wrote:
| It's a bachelor's thesis.
| als0 wrote:
| "There is only a single reference5 dated to 2010 indicating
| that Microsoft might use a similar approach for its NT kernel."
| cmpxchg8b wrote:
| Googling for it brings up a ton of results.
| raggi wrote:
| I found it very opaquely worded the whole way through. I think
| the work being presented is simply an implementation of the
| technique in eduos, but short of going and reading the paper I
| don't know.
| no92 wrote:
| If I'm not mistaken, this is just fractal mapping, which is very
| common. See https://wiki.osdev.org/Fractal_Page_Mapping
| userbinator wrote:
| It's amusing to see a concept that is explained simply in a few
| lines, become an entire bachelor's thesis.
| jdefr89 wrote:
| Isn't this just fractal page mappings? Am I missing something?
| voidmain wrote:
| I'm currently using recursive page tables for the OS I'm working
| on, but I'm probably going to change that. There are lots of
| different address spaces for different processes and (with IOMMU)
| devices, and it's nicer to be able to modify any of them rather
| than only the current one. I am leaning toward just assigning 2
| MiB of memory to page tables at a time and keeping a mapping for
| these (I don't want to map all physical memory in the kernel for
| security reasons).
___________________________________________________________________
(page generated 2025-12-25 23:01 UTC)