Yes, I assumed that you wanted to create a program which did not risk corrupting the system (i.e. guarantees that the system will continue running properly afterwards). Hence the remarks about that risk included in the first post.
For this discussion, I would define ‘map’ as in to create (or cause to be created) a virtual -> physical mapping that could end up in a processor TLB, i.e. creating a PTE mapping some virtual space to that physical address, even if the PTE is never referenced by real program flow (speculative execution could fetch it).
If everyone follows the rules, MM will guarantee that there won’t be TLB corruption. The rules are that you must only map memory that you own (i.e. that has been handed back to you by some allocation scheme which gives you exclusive access to the entire set of pages and guarantees that nobody else has created virtual to physical mappings for said pages), such that the cache characteristics of mappers of that memory can be tracked and coordinated. The simplest case of this is that there is only one mapper and they promise not to create multiple conflicting mappings after given exclusive use of a set of physical pages.
Mapping arbitrary physical memory regions pulled out of the hat (i.e. not explicitly allocated for your exclusive usage by a proper allocator of some sort) with \Device\PhysicalMemory does not count as following the rules and you are not guaranteed that there won’t now (or in the future) be a caching attribute conflict that will cause TLB corruption. For instance you are not protected against some innocent party creating a future mapping through whichever allocator rightfully owns that physical memory region with conflicting attributes with respect to an illegally created mapping.
The documentation for ZwMapViewOfSection alludes to this. “Do not use ZwMapViewOfSection to map a memory range from \Device\PhysicalMemory […] unless your driver has directly allocated the memory range through MmAllocatePagesForMdl or another method guaranteeing that no other system component has mapped the same memory range”.
I would avoid doing this even in the bug check path unless you really have no choice at all in the matter. While there may be some waiving of these risks when you are down the path where the system is already going to crash, it’s still in your best interest to make sure that the system is most likely to successfully complete writing the crash dump intact rather than experiencing a secondary failure along the way.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, April 08, 2010 10:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] PhysicalMemory and Address Space on x64
Not “destroy” but, rather, “consume”… that’s the problem to which I understood Mr. Kemp was referring.
Eh? Define “map.” Define “own.” (for that matter, define “never”… no, seriously.)
If you mean “Point a PTE to”, I certainly agree. At least if you want to keep the system running after you do so. You might, for example, want to “roll your own” memory dump prior to halting the machine.
If you mean “map using the Memory Manager DDIs” I’d say that using these API makes you at least partial “owner” of the memory… and – as long as the memory manager does the mapping – I don’t see how that could least to TLB corruption.
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer