I was doing Windows system programming and wondered if I can access a process' page table on source code level.
Here is what I know about page table related to virtual memory.
Let's suppose an user just runs a process called 'A' process on Windows OS(32bit).
First of all, the OS creates and maintains 4GB virtual address space for A process.
(2GB of it is Kernel address space and the other 2GB is User address space.
Any codes in User address space cannot directly access Kernel address space.)
Then, the OS creates and maintains a page table for A process in physical memory to map virtual memory address to physical memory address.
Here is my question.
After OS creates a page table for A process, is this page table mapped to A's Kernel address space so user can indirectly access the page table from source code?
Or the page table is not mapped to any of A's virtual address spaces but just resides only in physical memory so user cannot access the page table?
To speed up manipulation of page tables, the kernel normally makes one entry in the page directory point to the page directory. This makes all page tables mapped and accessible in the address space. However, as Raymond Chen has indicated, these are not accessible from user mode. There's no good reason to allow applications to mess with page tables. There are APIs to allocate (and map) regions of address space and those should be used instead.
You mean there are page table entries in the kernel address space of 'A' process' virtual memory, and those entries are mapped to the real page table residing in physical memory. So, the process can access these page table entries only if it has kernel mode, but the process does not have it. Therefore, the process cannot access its page table after all. Is it right?
Right. Accessibility of pages is governed by the current privilege level (user vs kernel), segment access rights and page access rights. The particular combination of these employed in the system does not let code running in user mode access kernel data, including the page directory and page tables.
Related
In studying shadow paging mechanisms, I learned of a case where a shadow page table starts out empty and only gets filled in as the guest VM accesses memory. It got me thinking about traditional page tables. When the OS is running and a page table becomes empty (perhaps when the page table's process terminates), I would think that page table gets released as a free page of memory.
Is there ever a case where an empty page table or even empty page directory table can exist during normal operations? Three cases I can think of are:
When the OS boots - but my understanding is that modern OSes like Linux start in real mode and then switch to paging mode, during which I would imagine process 1 gets its own page table with kernel mappings among other things. Is this correct?
If the last valid entry in a page table is then unmapped or swapped out - but I've also read that invalid entries could be used to store swap addresses, so not sure exactly.
When a new process is spawned - although I think similar to 1), a new process is started with kernel mappings and linked library mappings, so it would already have a small page table upon starting.
UPDATE: I learned that even in the shadow page table where it starts out "empty", it still has some mappings to hypervisor memory, so even then the page tables are not truly empty.
There's no point in having an empty page table, so I'll say no.
If you mean one particular table, then leaving it empty is a waste of memory. If you have an empty page table, you can free it, and in the place that pointed to the page table, you tell the CPU that there is no page table. For example, if a level-1 page table is empty, instead of pointing to it in the level-2 page table, you can put an entry in the level-2 page table which says "there is no level-1 page table for this address".
If you mean the entire set of page tables - so are there no pages at all - the CPU can't run any instructions without page tables (unless paging is turned off) so that's still a no. The CPU would triple-fault (x86) and reboot.
In Linux, there are functions such as pgd_offset, pmd_offset and pte_offset which are used to index to the pgd, pmd and pte. Who calls these functions? Does the MMU use these functions to walk the page tables?
My understanding is that the linux kernel creates a page table for each process and passes the base address of the page table to the page table base register so the MMU can access it. How does the MMU read the page table afterwards? Who uses those pgd_offset, etc functions if the MMU is the one reading the page tables?
How does the MMU read the page table afterwards?
The MMU is using hardware an accelerated method in order to read memory. The actual lookup is architecture-specific: just like the instruction parsing process.
Who uses those pgd_offset, etc functions if the MMU is the one reading the page tables?
Sometimes, kernel code want to lookup a struct page by a virtual address. It must use these functions in order to do this (AFAIK, there is no API for MMU address lookup. Therefore, it must be implemented in the kernel too).
In two level address translation, it's said that the first level page table (1K entries)will always be there in main memory for a process.
Out of 1K second level page tables , only those page tables will be there in memory which are currently in use.
Where will we store other second level page tables ( which are not currently in use) in the absence of any secondary storage (e.g. in embedded systems)?
If we can't swap out second level page tables from memory, is there no advantage of Two level Address Translation?
The advantage of a multi-level table for logical address translation without virtual memory is that one can have dynamic page table size (even if it is not paged out). Paging is just on possible benefit (however, systems with dedicated system address spaces can page page-tables without having nesting).
If paging is enabled in OS, a page table is used to map the virtual address to the actual physical address. To be more specific, consider Linux 32 bit OS on X86, the cr3 register has the starting address of the page table directory. I guess this is a virtual address. How will the CPU maps this virtual address to the physical address of the page table directory on RAM.
Which page table will be used for this address translation?
No, cr3 has the physical address of page table, not the virtual address. If cr3 contains the virtual address of page table, you'll fall into a logic dead loop and have no way to find page table.
The paging unit translates linear addresses into physical ones.
Set of linear addresses are grouped together to form a page. These linear addresses are continuous in nature - the paging unit maps these sets of contiguous memory to corresponding set of contiguous physical addresses called page frames. Please note that the paging unit is divided into RAM page frames of fixed size. For this reason, the pagination has the following advantages:
Permissions defined for the page will be valid for a group of linear addresses forming a page
The page length is the length of the page frame
The data structure that maps these pages to page frames, called a page table. These page tables are stored in main memory and the kernel is initialized before the resolution of the module management pages.
see to the link
Does page table per Process or per System ?. Is KERNEL maintain entire single shared page table for all process ?
Most OS's allocate the page table for each process and store the pointer of the table in the register and include it in the PCB