Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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

Doron_HolanDoron_Holan Member - All Emails Posts: 10,438
> I just don't like having long-term pending IOCTLs

Why?

d

Bent from my phone
________________________________
From: Jamey Kirby
Sent: ?1/?16/?2015 8:11 AM
To: Windows System Software Devs Interest List
Subject: Re: Re: Re: [ntdev] Re: [ntdev] User kernel communication via existing kernel objects

>> The classic example is: Are you using the handle from the user-mode app to signal the driver to do the unmap operation?

No, the driver has a watchdog thread. The thread calls KeWaitForSingleObject() on the EPROCESS of the app. When the app terminates or exits, the driver satisfies the wait and does the proper tear-down.

I tinkered with "Big Hanging DIrect IO" model. I just don't like having long-term pending IOCTLs.


On Fri, Jan 16, 2015 at 10:06 AM, > wrote:

the code in the IO path is less complex using events and shared memory.


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


---
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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



--
Jamey Kirby
Disrupting the establishment since 1964

This is a personal email account and as such, emails are not subject to archiving. Nothing else really matters.
--- NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers 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
d
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA