StrikerX3
commented
6 years ago Mapping virtual addresses into physical addresses is easily done with MmGetPhysicalAddress. On the other hand, converting physical addresses into virtual addresses is not cheap. So, in order to avoid performance penalties, all kernel emulation code will have to use guest addresses and convert them into pointers when needed. However, using pointers has caveats as explained below.
With the above function, we could make pointers into physical memory which we can use to manipulate structs, but if the data happens to cross the boundary between two virtual pages that map to non-contiguous physical addresses, writing data via the pointer will corrupt memory. This is a problem I'm trying to solve in an elegant manner and so far there have been three failed attempts.
It would be great if C++ offered a way to create a custom pointer with the same pointer syntax we're familiarized with while letting us do custom memory addressing. Unfortunately, that is not possible. The best we can do as far as my limited knowledge of C++ goes is to create a template class that stores the virtual address and overloads the pointer and arrow operators to provide direct access to the underlying data. In fact, this was my first attempt. I gave up on it when I realized pointers would have the issues mentioned above.
My second attempt involved pointers-to-members. It looked ugly as sin and suffered from the same problem with pointers, not to mention the verbose syntax for accessing deeply nested struct members and array indices.
My third attempt (in which I was aware of the pointer problems) involved a slightly modified version of the first design, where it would provide a pointer to either the actual data in the memory array if it would fit in a single physical page or a contiguous set of pages, or a pointer to a copy of the data which would have to be manually copied back into or refreshed from the guest memory. It provided methods that helped with those two operations, which was quite annoying to deal with since you had to manually invoke the methods after every change that had to be visible. I stopped working on it when it became too cumbersome in some cases (especially when dealing with LIST_ENTRY). Perhaps this could be partially automated by using copy/move constructors, destructors and assignment operators? I will explore this further.
The current implementation is mostly a placeholder that gets the job done. The memory manager in the kernel does much more work.
The goal is to implement all Mm functions (including any internal Mi functions and data structures), and go further and implement all Nt functions related to virtual memory and Ex functions related to pools.
Note that in the real kernel, the addresses produced by the internal memory allocation functions are in the virtual memory range reserved for the kernel -- 0x80000000 and above. These addresses map 1:1 to the physical memory area at 0x00000000, but we still need to map addresses to pointers and back again safely.