> if its supposed that “pointer” is pointing to resident memory, and if they are going
to just copy some data, why do they need to lock and map the memory?
why not just: copy(pointer, source, count);
There are quite a few situations when you want to actually access the target buffer in a context
that is different from the one in which you have received a pointer to it. For example, consider what happens if the target buffer resides in the userland;you have received a pointer to it in context of IOCTL call but may have to access it in context of arbitrary kernel thread or DPC at some point. Another example is the situation when the target buffer resides in pageable kernel memory and you have to access it in context of DPC.
This is why you build an MDL for the target buffer, make sure that the all the pages that back it up are actually resident in RAM, and then map it to the non-pageable area of the kernel
address space. After that you will be able to safely access it in any context.
First of all, the usage of the APIs is wrong…It’s not architecturally valid to call MmBuildMdlForNonPagedPool and then MmMapLockedPages because, as you noted, it doesn’t really make any sense. So, absent further context, I would agree that the code makes no sense for anything legitimate.
As for not so legitimate uses…The alternate mapping that you get from MmMapLockedPages is R/W. I’ve seen people use this type of thing for writing to kernel addresses that are marked as read only. This shouldn’t ever be necessary for normal development, but people do all sorts of strange stuff on the internet.
I should clarify that calling “MmMapLockedPages(KernelMode)” makes no sense. Wanting to map things in user mode might be a different story (with its own caveats).
Anton:
True, but then you would need to call MmProbeAndLockPages, not MmBuildMdlForNonPagedPool. If you’re calling MmBuildMdlForNonPagedPool it means that the buffer is already non-pageable and process context independent.
> True, but then you would need to call MmProbeAndLockPages, not MmBuildMdlForNonPagedPool.
Oh dear…I did not even notice this part - after all, the OP was speaking about locking and mapping memory, so that I automatically assumed MmProbeAndLockPages(). In fact, I think it could just be sort of typo on his behalf - he does not seem to be well-versed enough in KM development to make any distinction between these two.
he does not seem to be well-versed enough in KM development to make any distinction between these two.>
[/quote]
Oh boy. What is the point to insult the OP based on his experience.
BTW we have your personal testimony on Windows NT CC and MM that is a pure misconception. This is a pure off-topic but I believe it’s worth to debunk some misconception as you keep repeating them over and over. I take some examples from http://www.osronline.com/showthread.cfm?link=286222
1. “reverse mapping” is PA to VA mapping, not PA to a file as you think. “reverse mapping” is one to many mapping - one PA to multiple VAs from multiple address spaces. There is no problem to map a single physical page to a single file ( exactly what you referred as “convoluted approach” which I described ).
2. Windows is able to find all physical pages for a mapping since Windows NT inception, again contrary to your belief. 3. Starting from Win 7 there is a reverse mapping for PA to VA, again contrary to your belief.
4. Windows CC mapping in KM is not exactly the same as file mapping for UM as there is no VA descriptors in KM, i.e. you can’t use ZwMapViewOfSection to map into KM VA space, though CC and file mapping share the same structures to share residential physical pages. CC just maps residential pages in a free KM VA slot on demand from a file system driver.
5. Windows CC holds pages that are not always mapped in KM VA space and maps them on demand, this allows to have the cache working set for 32 bit OS that exceeds the 2 GB VA space limit for KM space if there is enough RAM, i.e you can have more than 2 GB of physical pages in the cache on 32 bit system with more than 2 GB RAM.
6. File mapping and the CC is backed by the same physical pages so the changes in a cached file are immediately visible for mapped file view and vise versa. That means that contrary to your belief modifications by the cached writes ARE IMMEDIATELY reflected in the file view that are mapped by the user apps. As we already know Windows does able to locate all “pages that back up a given file”. In the past there was a problem to locate all virtual addresses ( except by an exhaustive search of all page tables ) that are backed by a physical page for a particular file mapping but this is not an issue since Windows 7 that introduced a reverse mapping.
KM stands for Kernel Mode UM stands for User Mode VA stands for virtual address PA stands for physical address KM VA stands for kernel mode virtual address space, i.e. a top half of VA space
I thought the question was legit. He found a code sequence that doesn’t make
sense and asked if anyone knew why someone would do this. Not sure why this
could call for derision.
The comment says they’re doing this to get write access, which would match
my description:
// enable write access to service descriptor table
bool initSysCallHooking()
The exported kernel virtual address is marked as read only. So, they build
an MDL to describe the underlying physical pages for the virtual address
range and then create an alternate kernel mapping that is R/W mapping. No
legitimate uses of this sequence.
> Oh boy. What is the point to insult the OP based on his experience.
I dunno, but if I am not well-versed in something (which is, apparently, 99+% of things in existence anyway) and it gets pointed out to me, I don’t see any reason why I should somehow feel “insulted”.
You seem to be taking things a way too personally…
BTW we have your personal testimony on Windows NT CC and MM that is a
pure misconception. This is a pure off-topic but I believe it’s worth to debunk
some misconception as you keep repeating them over and over.
I am not going to reply to it it here because if I do it would be me who gets all the blame for the hijacked thread, although it is very obviously not me who attempts to do it. It had happened on more than one occasion, and I don’t see any reason why it should work differently here. After all, as you can see, Peter even claims to have had discovered “Anton’s law”…
We can either start a separate OT thread on NTDEV, or, conversely, move it to NTTALK, which seems to be dead these days. Please let me know which one you prefer…