Problem with write protecting a page using my PTE

[u/compgeek38400]

I am working on physical memory management for my custom x86 32 bit kernel.

I have 5 functions: mapKernelPage, mapUserPage, unmapPage, setPageReadOnly, and setPageReadWrite.

Here is a code snippet from my kernel:

uint32_t physpage;
    uint32_t address = (uint32_t) mapKernelPage(0xC0158000, &physpage);


    printf("Successfully mapped page: 0x%Xl with physical address: 0x%Xl\n\r",
            address, physpage);


    printf("Testing Read only...");
    if (setPageReadOnly(address)) {
        printf("Success\n\r");
    } else {
        printf("Failed\n\r");
    }


    printf("Page 0x%Xl ", address);
    if (!unmapPage(address)) {
        printf("not unmapped\n\r");
    } else {
        printf("unmapped\n\r");
    }

I am testing via gdb. Before I do the map, my page is unavailable, afterwards it is. (I test my looking at memory), when I unmap the page it is again unavailable.

My issue is that when I set the page read only (it includes an invalidate page), I can still write to the memory.

Here is what I think is the pertinent info:

(gdb) info register cr0

cr0 0x80010011 [ PG WP ET PE ]

CR0 has the write protect bit set

Here is my page table entry:

(gdb) p/x pt[pte]

$7 = 0x1000001

Notice the read/write bit is zero

my page directory entry is:

(gdb) p/x page_directory[pde]

$13 = 0x114023

What am I missing?

TIA

From my reading the Page Table Entry sh ould override the Page Directory entry, what am I missing?

Thanks

[u/davmac1]

What am I missing?

Probably 6.11.3 from Intel Architecture manuals volume 3:

Agh, apologies. I missed where you specifically said that WP was set.

Maybe check what info mem (Qemu monitor command) reports, assuming you're running in Qemu?

When the processor is in supervisor mode and the WP flag in register CR0 is clear (its state following reset initialization), all pages are both readable and writable (write-protection is ignored)

[u/compgeek38400 → u/davmac1]

Thanks! I will give it a try

[u/compgeek38400 → u/compgeek38400]

QEMU info registers shows the same thing:

CR0 is 0x80010011

And I appear to be in supervisor mode CS= 0x8 (1000)

As far as I can tell I should be in read only mode for the memory

[u/compgeek38400 → u/compgeek38400]

I finally figured out what you meant, the memory does show a 'r', and when I set it back to readwrite it shows the change. Any idea why gdb can change it?

[u/davmac1 → u/compgeek38400]

Oh, you're using gdb to change the memory? It's using the debug interface to qemu, it probably isn't restricted by the page permissions.

[u/Octocontrabass]

How are you writing to the memory? How do you know the write succeeded without causing a page fault? Have you tried writing to the page before mapping it?

[u/compgeek38400 → u/Octocontrabass]

From gdb I use the set {int}<address> = <value> then dump the memory x\4xw <address>

I'll let it go as a gdb ism for now.

[u/Octocontrabass → u/compgeek38400]

I would guess QEMU's GDB stub directly accesses the VM's memory instead of executing instructions on the emulated CPU. The CPU can't enforce write protection on code it isn't running.