Where are the page tables?

[AeroASM]

I know this, that the page tables are at offset C0000000 and the PD is at C0300000.

1. Why does the upper 20 bits of a virtual address give a dword index into the page tables from C0000000?
2. Why can a user mode process not access C0000000, but a driver can?
3. When a driver accesses C0000000, which process do the page tables belong to?
4. Why is the PD at C0300000?
5. How can I gain access to another process's page tables?

[TimRoberts]

The location of the page tables is different on different operating systems.  Windows 9X puts them at FFCFF000, for example.  They don't actually have to present in the virtual address space at all, although Windows does so for convenience.

> 1. Why does the upper 20 bits of a virtual address give a dword index into the page tables from C0000000?

That's not actually how it works.  It's a two-level scheme.  CR3 points to the page table directory.  The top 10 bits of the virtual address are the dword index into the page table directory of the page table that contains this page.  The next 10 bits are the dword index into that page table of the entry for this page.  The bottom 12 bits are just an offset into that page.  The processor handles all of this every time an address is used.

> 2. Why can a user mode process not access C0000000, but a driver can?

In Windows, the pages for all addresses at linear 80000000 and above are marked with the "S" bit, which means they can only be accessed when the current code segment is at ring 0.  User code runs in ring 3, drivers run in ring 0.

> 3. When a driver accesses C0000000, which process do the page tables belong to?

Whatever process was last scheduled into memory.  Drivers have to be careful about that; when a hardware interrupt occurs, the driver does not know which process was interrupted.

> 4. Why is the PD at C0300000?

I don't know that it is, but why not?  The location doesn't matter.  The hardware doesn't use the linear addresses of these tables.

> 5. How can I gain access to another process's page tables?

You can't.  When your process is running, your pages are the only ones mapped into the virtual address space.  In order to access another process, you have to force a switch to that process, and when that happens, your process is gone.  That means it can only be done from a driver.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[Phil]

I think the VirtualAllocate(Ex) function allows processes to share pages if they wish. I haven't used any of those features yet but I remember that it's possible. That's only be cooperation though. The protection mechanism usually prevents all access to other memory.

Edit: I think that I *might* be right about being able to use VirtualAllocateEx to create a named mapping for memory that can be shared but it appears to be the *complicated* and most difficult way to accomplish the task. I noticed another post here about sharing memory that was very clear and I also discovered the following link at MSDN that gives a fairly simple example of sharing memory with other processes:

   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/creating_named_shared_memory.asp

I'm posting this in response to AreoASM's question concerning accessing memory from other processes.

[AeroASM]

> 1. Why does the upper 20 bits of a virtual address give a dword index into the page tables from C0000000?

That's not actually how it works.  It's a two-level scheme.  CR3 points to the page table directory.  The top 10 bits of the virtual address are the dword index into the page table directory of the page table that contains this page.  The next 10 bits are the dword index into that page table of the entry for this page.  The bottom 12 bits are just an offset into that page.  The processor handles all of this every time an address is used.

I know that that is not how it works, but it does work. By some magic, it works.

I thought that it would be more logical for the PD to be at C0400000, since if all the PTs were loaded at C0000000 they would finish at C03FFFFF

[hutch--]

Hi Tim,

Welcome on board.

For any who are not familiar, Tim is a partner in Providenza & Boekelheide, Inc. which is a specialised company that has many years of experience in developing low level drivers  for operating systems including Windows.

Tim also wrote some of the original code for the MASM32 library when it was first being developed which was very useful in getting it up and going.

[The Dude of Dudes]

Hello Again AeroAsm!

You are quite right to be curious why the PD is mapped at 0xC0300000. It actually doubles as a Page Table to map ALL the Page Tables starting at address 0xC0000000. Offset 0x00300000 into the Page Tables translates into virtual address 0xC0000000. Cool huh? DriverEntry runs in the context of the calling process. You can switch to a different process' memory context by changing the value in CR3. Look into EPROCESS blocks in kernel space and you'll find the field Pcb.DirectoryTableBase (Pcb is a KPROCESS struc inside the EPROCESS struc, 4-f's inc files show all this). Find the Eprocess block for the desired process and use the value in this field in CR3 and you've switched mem context. However, you also switch stacks, so it is not a recommended way to access another process' memory but it does work. 

[Opcode]

DriverEntry runs in the context of the calling process.

Hi kernel programmers !

Just a little correction: DriverEntry routines runs in the context of the SYSTEM process.

Regards,
Opc0de