RE: Re: Re: Re: [ntdev] User kernel communication via existing kernel objects

Not in my experience. You have to be aware of the problems of signaling the same event multiple times, you have to ensure that the writer and the reader are not attempting to read/write the same area simultaneously. It all LOOKS magical and wonderful once you get it to work, but it’s also very easy to break when you make changes.

And then there’s the problem of having that shared section, and how you tear it down. We have debated this many, many, many, many times here on NTDEV. I have, after a long struggle, become a believer that shared memory sections mapped back into user space are evil, due to security and issues with tear down. The classic example is: Are you usign the handle from the user-mode app to signal the driver to do the unmap operation? If so, What, precisely, is your plan to handle the case when somebody calls DuplicateHandle on that handle?

If you *really* want to use a shared memory scheme and not an inverted call, there IS one really terrific way to “get all the benefits of shared memory without the pain”… and that is to use what we call a “Big Hanging Direct I/O” – In this model, the app allocates the shared memory buffer and sends an IOCTL (using direct I/O) with the OutBuffer pointing to the entirety of this buffer. The driver keeps this IOCTL in progress until the app exists. Voila! Shared mapping.

Peter
OSR
@OSRDrivers