I think putting it up somewhere would be helpful (maybe not now, but definitely in the future if you need assistance on here again). Meanwhile, the fact that the page is marked present but not writeable led me to investigate the UEFI spec, which says:
Quote:
Paging mode is enabled and any memory space defined by the UEFI memory map is identity
mapped (virtual address equals physical address), although the attributes of certain regions
may not have all read, write, and execute attributes or be unmarked for purposes of platform
protection
This is in section 2.3.4 - x64 Platforms of the UEFI spec. From my experience, the firmware does not set the WP bit in CR0, so even ring0 code cannot write to pages mapped without the PAGE_WRITE flag (0x2). Again, I have no clue what is actually in those pages (if you were able to write to the page pointed to by CR3, it’s unlike the physical page tables were mapped as read-only — so it’s probably not paging structures?).
If you wish to pursue this (I am personally quite curious what’s in there) feel free, but otherwise my current advice is: 1. just accept that the firmware marks this as read-only; 2. if you wish to set all memory to 0, do it after setting up your own page tables; 3. don’t bother zeroing all memory.
(for 3: you can do it selectively, like zeroing our stack space and memory allocated by kmalloc and your page frame allocator — you certainly don’t want to do it for all of physical memory)