MmMapLockedPagesSpecifyCache and MmUnmapLockedPages

My question is about this blurb from MSDN:

/////////////////////////////////////////////////////////////////////
MmMapLockedPagesSpecifyCache

If AccessMode is UserMode, be aware of the following details:

The routine returns a user address that is valid in the context of the process in which the driver is running. For example, if a 64-bit driver is running in the context of a 32-bit application, the buffer is mapped to an address in the 32-bit address range of the application.

MmUnmapLockedPages

Note that if the call to MmMapLockedPages or MmMapLockedPagesSpecifyCache specified user mode, the caller must be in the context of the original process before calling MmUnmapLockedPages. This is because the unmapping operation occurs in the context of the calling process, and, if the context is incorrect, the unmapping operation could delete the address range of a random process.
/////////////////////////////////////////////////////////////////////

What are the side-effects of not calling MmUnmapLockedPages? Lets assume that MmUnlockPages was already called from another thread and calling MmUnmapLockedPages would cause a system crash. If we can safely detect this case, avoiding the call to MmUnmapLockedPages would save us from the crash but could be considered a resource leak. Is it though? What kind of resources?

I realize that I have a design problem. I just want to know how to measure the impact and prioritize.

On Nov 1, 2017, at 1:27 PM, xxxxx@hotmail.com wrote:
>
> What are the side-effects of not calling MmUnmapLockedPages?

Physical memory leak. Those pages could never be used again, even though the process they belonged to is gone.

> Lets assume that MmUnlockPages was already called from another thread and calling MmUnmapLockedPages would cause a system crash. If we can safely detect this case, avoiding the call to MmUnmapLockedPages would save us from the crash but could be considered a resource leak. Is it though? What kind of resources?

Physical memory, which matters. If you can safely detect this case, the RIGHT answer is to force a switch to the original process and unmap.

> I realize that I have a design problem.

How can you possibly get into a situation where you cannot undo what you have done?

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

To begin with, the approach that you are speaking about (i.e.mapping an MDL that describes kernel-allocated pages into the userland) is not the best one under Windows due to security considerations, although this is basically the way other OSes implement mmap() in drivers. If you want to share memory between an app and a driver under Windows it is better to do it the other way around, i.e. to map an MDL that describes a userland buffer into the kernel address space.

If you do it the way you have described both mapping and unmapping should be done in response to IOCTL that a driver gets in context of the target app. Therefore, as long as your driver knows what it is doing, the scenario that you have described just cannot occur. At the same time you are, indeed, going to get an absolutely unnecessary headache, and will have to worry about quite a few extra things that mapping a userland buffer into the kernel address space would spare you from…

Anton Bassov

On the process termination the system will try to free(unmap) the related VAD and remove physical to virtual mappings which decrements PFN shared count. This is nearly equivalent to a call to MmUnmapLockedPages which also removes VAD and decrements PFN shared count.

Anyway, I am afraid that such design might result in some sort of a resource leak or system crash.

>or system crash

There should be PROCESS_HAS_LOCKED_PAGES bug check: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x76--process-has-locked-pages

I believe no. The pages are not locked. They are mapped but not locked as MmUnlockPages was called so Process->NumberOfLockedPages is 0.

You will not get that specific bugcheck, but it’s still illegal to call MmUnlockPages before MmUnmapLockedPages. After the pages are unlocked the memory manager can trim and repurpose them, so you may end up with PTEs pointing to pages that are now owned by somebody else. If the mapping is a user mapping, that’s a security hole. It can also cause random corruptions if the new owner maps the pages with a different caching type.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, November 4, 2017 2:24 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] MmMapLockedPagesSpecifyCache and MmUnmapLockedPages



I believe no. The pages are not locked. They are mapped but not locked as MmUnlockPages was called so Process->NumberOfLockedPages is 0.