OSDev.org

I've been reading the Intel manuals lately, and I found something that makes me wonder how much of a hack self-mapped page directories are.

Basically, I see a problem with using a page directory entry as a page table entry as well. The problem is bit 6: the Dirty bit. For PTEs, the processor will set it when the corresponding page is written to. For PDEs, it is reserved and is supposed to be 0. I'm guessing that nothing happens if it's set to 1, but the manuals are pretty clear on this point (from section 3.7.6 on page 3-30 of IA-32 Volume 3):

In a page-directory entry that points to a page table, bit 6 is reserved and should be set to 0.

So I doubt that this technique has been "blessed" by Intel.

Does anybody think this matters? If not, why not? If so, what should be done about it? Is there any technique that is similarly clean (the hackish nature of it notwithstanding) as the self-mapped page directory?

Hi,

Colonel Kernel wrote:Basically, I see a problem with using a page directory entry as a page table entry as well. The problem is bit 6: the Dirty bit. For PTEs, the processor will set it when the corresponding page is written to. For PDEs, it is reserved and is supposed to be 0. I'm guessing that nothing happens if it's set to 1, but the manuals are pretty clear on this point (from section 3.7.6 on page 3-30 of IA-32 Volume 3):

In a page-directory entry that points to a page table, bit 6 is reserved and should be set to 0.

It seems this would depend on which Intel manual you're reading. My hardcopy version says (from section 3.7.6 on page 3-27 of volume 3):

Dirty(D) flag, bit 6
Indicates whether a page has been written to when set. (This flag is not used in page-directory entries that point to page tables). [following/unrelated text skipped]

The newest electronic version I have (order number 253668-018), which includes long mode and virtualization extensions, says the same thing in from section 3.7.6 on page 3-29 of volume 3A.

Of course there's a major difference between should and must....

Perhaps a more worrying thing could be found in Chapter 5 - Interrupt 13, where it lists possible causes for general protection faults, including:

- If the PAE and/or PSE flag in control register CR4 is set and the processor detects any reserved bits in a page-directory-pointer-table entry set to 1. These bits are checked during a write to a control registers CR0, CR3, or CR4 that causes a reloading of the page-directory-pointer-table entry.

Colonel Kernel wrote: So I doubt that this technique has been "blessed" by Intel.

Does anybody think this matters? If not, why not? If so, what should be done about it? Is there any technique that is similarly clean (the hackish nature of it notwithstanding) as the self-mapped page directory?

I wouldn't be surprised if "self-mapping" is the reason why bit 5 remains reserved...

I guess I should also point out (before anyone gets worried about "self-mapping" in their long mode paging code, like I just did), that in the newest Intel manual there's a table describing which reserved bits are actually checked in different modes (see table 3-4 on page 3-44 and table 3-5 on page 3-45 in section 3.10.3.1 "Reserved Bit Checking").

According to these tables bits 5 and 6 are only ever checked in page directory pointer table entries when PAE and/or PSE is enabled and long mode is disabled.


Cheers,

Brendan

what may get evil in this regards is when you try to use "read-only" protection from page directories. E.g. let's say you want to make sure that C0000000 .. C0400000 is not writable because it contains your kernel code, if you use self-mapping, that also means the mappings of the corresponding page table cannot be changed (while you may have wanted to use the protection as a shortcut to "every page within that page directory shouldn't be writable").

@Brendan:
I downloaded the new version of the manual, and it matches what you said (it's new as of March). Unfortunately, the issue is still somewhat unclear. I suspect I could get away with using the technique, but it would leave me with a very uneasy feeling...

Colonel Kernel wrote: Basically, I see a problem with using a page directory entry as a page table entry as well. The problem is bit 6: the Dirty bit. For PTEs, the processor will set it when the corresponding page is written to. For PDEs, it is reserved and is supposed to be 0. I'm guessing that nothing happens if it's set to 1, but the manuals are pretty clear on this point

So what wrong could happen ? you modify a mapping in table X, making X->directory became dirty (because of its place as a PT in self-mapped directory), which means the PDE for X is now dirty in your "real" directory, right ?
If you fear this might be an issue, just reset the dirty bit of page directories you have affected when you modified the mappings, then, and noone will ever notice

I know that this isn't proof that self mapping the PD is "ok", but if it's any consolation, the Windows 2000/XP kernel does this. Not only that, but Intel in the past has contributed to Windows code, so it is resonable to assume Intel is at the very least aware of this "trick".

Given that, I would imagine that if there were any issues with doing this, Intel would have mentioned so in the documentation.

proxy

Pype.Clicker wrote: If you fear this might be an issue, just reset the dirty bit of page directories you have affected when you modified the mappings, then, and noone will ever notice

Heh. My fear is that CPUs notice things very quickly, but now that I think about it, a CPU would only notice when handling a TLB miss for a virtual address that would "hit" the modified PDE... Perhaps I could prevent that on the CPU that's modifying page tables, but what about other CPUs running threads in the same address space? It still sounds hacky to me...

Besides, by attempting to clear the dirty bits in the page directory, you'd be inadvertently setting one of them -- in the PDE-pretending-to-be-a-PTE for the page directory itself!

I know that this isn't proof that self mapping the PD is "ok", but if it's any consolation, the Windows 2000/XP kernel does this. Not only that, but Intel in the past has contributed to Windows code, so it is resonable to assume Intel is at the very least aware of this "trick".

Heh... If the OS with 90% market share does it, it must be OK, right? Any idea what Linux does?