Hi guys,
As I know I can use MmMapIoSpace to map a physical memory into virtual
memory. Why MSFT desgin \Device\PhysicalMemory? On previuse thread people
say it will cause cache and non-cache confilict by using ZwMapViewOfSection
to map \Device\PhysicalMemory.
Fan Zhang
Really… you want to use the full-text search feature before you ask.
But, since you didn’t… here’s the answer. Read THE WHOLE THREAD:
http://www.osronline.com/showThread.cfm?link=179688
Peter
OSR
This is an informative thread, particularly when read together with the
following two threads linked therein:
http://www.osronline.com/showThread.cfm?link=173359; and
https://www.osronline.com/showthread.cfm?link=164773.
I do wish to take issue with one thing. In the second thread, Pavel
Lebedinsky states that:
“This is by design. If a physical page is already mapped with a particular
cache attribute, win7 will detect this and use the same attribute when
mapping a view of \Device\PhysicalMemory.”
This statement is incorrect. In fact win7 ignores potential cache conflicts
when mapping physical memory within the PFN database via the
\Device\PhysicalMemory section object. The mapping usually (if not always)
succeeds with the requested cache attributes, and with processor TLB
corruption as the likely result.
Pavel’s statement is correct as regards the behavior of MmMapIoSpace which
implements a cache override for pages within the PFN database. MmMapIoSpace
has other problems, however, and will bugcheck in the driver verifier if you
try to read the entire physical memory map using it.
Regards,
George.
I checked win7 sources and I think my statement below is correct. Have you looked at the actual PTEs to see what cache attribute they use?
Technically, the behavior I described is not part of any contract and drivers should not rely on it, but I still want to make sure the current code does what it’s supposed to do.
(Also note that even in win7 it’s still possible to create a conflicting mapping through Device\PhysicalMemory. For example, the original mapping could be freed, and the physical pages could then be mapped by somebody else using a different attribute. This is why mapping memory that you don’t own is unsafe).
Thanks,
Pavel
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Friday, November 26, 2010 3:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question about \Device\PhysicalMemory
This is an informative thread, particularly when read together with the following two threads linked therein:
http://www.osronline.com/showThread.cfm?link=173359; and https://www.osronline.com/showthread.cfm?link=164773.
I do wish to take issue with one thing. In the second thread, Pavel Lebedinsky states that:
“This is by design. If a physical page is already mapped with a particular cache attribute, win7 will detect this and use the same attribute when mapping a view of \Device\PhysicalMemory.”
This statement is incorrect. In fact win7 ignores potential cache conflicts when mapping physical memory within the PFN database via the \Device\PhysicalMemory section object. The mapping usually (if not always) succeeds with the requested cache attributes, and with processor TLB corruption as the likely result.
Pavel’s statement is correct as regards the behavior of MmMapIoSpace which implements a cache override for pages within the PFN database. MmMapIoSpace has other problems, however, and will bugcheck in the driver verifier if you try to read the entire physical memory map using it.
Regards,
George.
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
Pavel,
Thanks for taking the time to check into this. I did look at the PTE’s a
while back. But I will check it again and see if I can still reproduce the
problem.
(Also note that even in win7 it’s still possible to create a conflicting
mapping through Device\PhysicalMemory. <
That is true and I would not wish to trivialize this risk. The person who
will be responsible for the consequences needs to understand the risks and
make the decision on whether to proceed. Also, \Device\PhysicalMemory is
well-known and commonly subverted, which limits its value when responding to
malicious code.
The verifier asserts when MmMapIoSpace is called for a page that is within
the PFN DB but for which the reference count is zero. In that case the
cache attribute in the PFN DB is not valid. The verifier should do the same
for \Device\PhysicalMemory, if (or when) the cache override is properly
implemented.
Regards,
George.
“Pavel Lebedynskiy” wrote in message
news:xxxxx@ntdev…
I checked win7 sources and I think my statement below is correct. Have you
looked at the actual PTEs to see what cache attribute they use?
Technically, the behavior I described is not part of any contract and
drivers should not rely on it, but I still want to make sure the current
code does what it’s supposed to do.
(Also note that even in win7 it’s still possible to create a conflicting
mapping through Device\PhysicalMemory. For example, the original mapping
could be freed, and the physical pages could then be mapped by somebody else
using a different attribute. This is why mapping memory that you don’t own
is unsafe).
Thanks,
Pavel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of George M. Garner Jr.
Sent: Friday, November 26, 2010 3:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question about \Device\PhysicalMemory
This is an informative thread, particularly when read together with the
following two threads linked therein:
http://www.osronline.com/showThread.cfm?link=173359; and
https://www.osronline.com/showthread.cfm?link=164773.
I do wish to take issue with one thing. In the second thread, Pavel
Lebedinsky states that:
“This is by design. If a physical page is already mapped with a particular
cache attribute, win7 will detect this and use the same attribute when
mapping a view of \Device\PhysicalMemory.”
This statement is incorrect. In fact win7 ignores potential cache conflicts
when mapping physical memory within the PFN database via the
\Device\PhysicalMemory section object. The mapping usually (if not always)
succeeds with the requested cache attributes, and with processor TLB
corruption as the likely result.
Pavel’s statement is correct as regards the behavior of MmMapIoSpace which
implements a cache override for pages within the PFN database. MmMapIoSpace
has other problems, however, and will bugcheck in the driver verifier if you
try to read the entire physical memory map using it.
Regards,
George.
—
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