search

KernelTestFramework / ktf

Kernel Test Framework
BSD 2-Clause "Simplified" License
140 stars 18 forks source link

Add dedicated mechanism for page tables mapping/unmapping #333

Closed wipawel closed 11 months ago

wipawel commented 11 months ago

This closes #66.

wipawel commented 11 months ago

I guess the overall functionality makes sense but I have my problems with wrapping my head around the prototypes of [un]map_pagetables(cr3_t *, cr3_t *) .... I just cannot compute to map/unmap a "page table" in a page table.

I see that the implementation is walking the "from" page table and adding/removing existing mappings in the target page table. But, IMHO, it would be much more intuitive if the interface would simply to map/unmap a range of pages at a given virtual address. But then, we already have that -- kind of.

So, what's the use case for all of this? Merging page tables seems to be really a special case I simply cannot think of being useful in a general manor.

In KTF the page tables themselves are not mapped in the address space. Before the 4978793981af726456cb9cd77d93368047ec6c82 only initial page tables were mapped and now none of them except the tmp_mfn used for temporal mappings during page tables operations. However, for various tests (PoCs) we do need to access and manipulate the page tables to construct specific scenarios. There is a bunch of helper functions like get_pdpe(), get_pde, get_pte() , which do not map the page table entry, yet they return a pointer to its entry. To make them usable user has to map the page table upfront. Before it was necessary to use map_used_memory() which was an ugly hack to map the page tables among other unnecessary things. Now there is the (un)map_pagetables_va() coming with this change. The (un)map_pagetables() are just here to map entire page table at once without specifying particular virtual address. The from_cr3 and to_cr3() just indicate which page table into what address space. It's possible for example to map user_cr3 page tables into cr3 (kernel) address space although I don't think it would be every used. The main purpose is to map "our own" page tables into "our own" address space.

minipli-oss commented 11 months ago

In KTF the page tables themselves are not mapped in the address space.

Ok

Before the 4978793 only initial page tables were mapped and now none of them except the tmp_mfn used for temporal mappings during page tables operations. However, for various tests (PoCs) we do need to access and manipulate the page tables to construct specific scenarios.

Makes sense.

There is a bunch of helper functions like get_pdpe(), get_pde, get_pte() , which do not map the page table entry, yet they return a pointer to its entry. To make them usable user has to map the page table upfront. Before it was necessary to use map_used_memory() which was an ugly hack to map the page tables among other unnecessary things. Now there is the (un)map_pagetables_va() coming with this change. The (un)map_pagetables() are just here to map entire page table at once without specifying particular virtual address. The from_cr3 and to_cr3() just indicate which page table into what address space. It's possible for example to map user_cr3 page tables into cr3 (kernel) address space although I don't think it would be every used. The main purpose is to map "our own" page tables into "our own" address space.

And I guess that's where my confusion came from. I was under the assumption that you're trying to merge address spaces but simply mapping the page table pages is something completely different.

Sorry my confusion :D