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

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

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


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

Doron_HolanDoron_Holan Member - All Emails Posts: 10,499
> 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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA