Mapping Kernel Memory into application user space from a different process context

NTDEV
1

Hi,
I need a shared memory between storport miniport driver and a user application.

I know how to map a kernel memory to user space of an application in a regular WDM driver. However I would like find out how to do this from the storport miniport driver?

Here is what I am doing to achieve that.

  1. From the user application I pass in the processId of the application to storport miniport driver via Storport Miniport IOCTLs. Here the processId corresponds to the process into which I want to map the kernel memory.
  2. Because storport miniport driver IOCTL handling routines run at DISPATCH LEVEL, I queue in a routine to a driver thread that will call ZwMapViewOfSection etc… to perform the memory mapping to the process. Because ZwMapView… has to be called at PASSIVE LEVEL.
  3. Now the problem is ZwMapViewOfSection routine takes process handle (of the process into whom use space you want to map the memory)as one of its arguments. I get the process handle by Calling ZwOpenProcess passing the processId in step1. This Handle I am passing to the ZwMapViewOfSection routine.

All the ZwMap… calls are successful and the calls gives a user virtual address. However when I am trying to access the locations at the returned address, Application is raising Unhandled exception saying Access Voilation.

Anybody has success with this kind of exercise? Are there any gotchas that I need to be aware of while doing this?

Actually I need to do this because I need a shared memory that is accesible by both an application and the storport miniport code.

Any help would be appreciated!

Thanks,
-Subba

2

> I need a shared memory between storport miniport driver and a user application.

This is what you think. However, it does not imply that you ACTUALLY need it - although sharing a buffer between an app and a driver, indeed, may be beneficial in some cases, these cases are pretty rare. In your particular case, assuming you are about to access memory at elevated IRQL, how are you going to synchronize an access to it between an app and a driver (I already don’t mention the fact that shared section
is not the best approach here anyway) Could you please explain to us why you think you need to share a buffer???

Anton Bassov

3

I want to implement a unidirectional PIPE between driver and application. I resolve the access synchronization issue between the driver and app by maintaining separate put and get pointers. My driver will have some asynchronous messages that needs to be delivered to application process. Driver is the producer and application is the consumer.

I know it may bring-out a lot of what if? but for my need I guess a PIPE implemented using shared memory is good enough.

4

Under Windows, you may want to share it when shared buffer approach offers some distinct advantages over inverted call (these cases are quite rare). No matter how you look at it, your particular case does not fall into this category - in your particular situation one should UNDOUBTEDLY use the inverted call. In fact, your situation
is just a classical book one when inverted call should be used - after all, one of your requirements is asynch notification, and the amounts of data involved are predictable…

Anton Bassov

5

> Actually I need to do this because I need a shared memory that is accesible by both an application

and the storport miniport code.

Allocate in the app and then pass the MDL to the driver.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

> I know it may bring-out a lot of what if? but for my need I guess a PIPE implemented using shared

memory is good enough.

No, use inverted calls instead of this nightmare. The app sends overlapped “read pipe” IOCTLs, and the driver pends them and then satisfies them when some data arrived.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

7

+1

http://www.osronline.com/article.cfm?id=94

Good luck,

mm

Maxim S. Shatskih wrote:

> I know it may bring-out a lot of what if? but for my need I guess a PIPE implemented using shared
> memory is good enough.

No, use inverted calls instead of this nightmare. The app sends overlapped “read pipe” IOCTLs, and the driver pends them and then satisfies them when some data arrived.

8

Thanks Anton, Maxim & MM for the suggestion of using inverted calls and the corresponding link. It should be suffice for asynch notification.

BTW I was able to succefully map a piece of memory into intended application user address space. Even from the storport miniport driver.

Now I have two options :slight_smile:

Thanks,
-Subba

9

use MmMapLockedPagesSpecifyCache.
Good Luck

2009/3/1

> Thanks Anton, Maxim & MM for the suggestion of using inverted calls and the
> corresponding link. It should be suffice for asynch notification.
>
> BTW I was able to succefully map a piece of memory into intended
> application user address space. Even from the storport miniport driver.
>
> Now I have two options :slight_smile:
>
> Thanks,
> -Subba
>
> —
> 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
>