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

Home NTFSD

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/


Using private IOCTL codes to communicate with a minifilter driver

0xrepnz0xrepnz Member Posts: 102

Certain APIs can only be invoked in a minifilter I/O processing callback context. This can happen for example because these APIs send I/O below the specific FLT_INSTANCE used as a parameter. When the FILE_OBJECT comes from a non-minifilter component (Such as other kernel callbacks etc) it's not safe to skip filters and send I/O below our minifilter instance. The problem is, In certain cases we need to be able to use these APIs outside of the minifilter callbacks.

One suggested solution to handle these kind of cases is to send an internal IOCTL on this FILE_OBJECT and handle PRE IRP_MJ_INTERNAL_DEVICE_CONTROL in our minifilter. If the IOCTL code fits to some magic code of ours, we assume it's our request and now we can use these APIs because we run in the context of an I/O request (PreInternalDeviceControl). Obviously the problem with this suggested solution is that some other driver can use this same IOCTL code for it's own purpose.. In other words, It does not pass the 'Our filter is stacked on top of itself' test. We can mitigate this by putting a random GUID at the beginning of the request struct (So we will know that our driver generated the IRP) but it's still not an elegant solution..

Is there any other way to solve this issue more elegantly? Is the suggested solution (Having some kind of non-public IOCTL code + putting a GUID signature field at the beginning of the input buffer) ok?

Thanks in advance,
Ori

- Ori Damari
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online