Making sure the IO manager evaluates the security of your device

Last time I wrote about how the IO manager handles the creation of file handles and pointed out a potential security hole.  If there is a namespace (or path) after your device’s name in the path passed to CreateFile, the IO managed does not evaluate the security settings set on your device and relies on your driver…

1

Devices and namespaces (or how the IO manager handles file creation)

Ever wonder how the creation of a handle works?  It doesn’t matter type of resource the handle you are opening is backed by (a COM port, a file, a network share, a custom piece of hardware, etc), it all goes through CreateFile (which should be a little obvious since the only way to open an type of handle…

4

Creating symbolic links for an anonymous FDO or filter

As I wrote about previously, naming your FDO has some side effects that you may not want to incur. But what if you want to give your device a fixed symbolic link name (by calling IoCreateSymbolicLink), such as \DosDevices\Foo1, in addition to your device interface GUID? Does an unnamed FDO (or filter exclude the possibility…

1

Having two names is not necessarily better than one

Every physical device object (PDO) must have a name. Furthermore, if you read the entire MSDN page, you see that any device attached to the PDO must not have a name. Why does such a rule exist? To answer this question, let’s explore what happens if more than one device in the stack has a…

3

Problems with not having a current IRP stack location, part 2

This problem falls into the category being hidden by a macro that does not indicate in its name what it touches. If you call IoMarkIrpPending on an IRP that you allocated in your driver, chances are that you are corrupting memory. First, let’s look at the implementation of this function (from wdm.h): #define IoMarkIrpPending( Irp…

2

Your completion routine context can be anything you want

It sounds obvious, but sometimes it needs to be stated. For instance, let’s say that you are allocating your own IRP, your context contains I/O related data (like a URB) and you encounter the issue where the DeviceObject passed to your I/O completion routine is NULL. Adding another stack location is one solution I wrote…


Filtering HID collections and setting I/O flags

Over the past 3 years or so, I have been casually referring to KMDF as the ultimate driver compat layer. Just like Windows has an application compatibility layer which shields applications from OS changes, KMDF provides the same type of compatibility across device stacks. For the most part each stack implements WDM as per the…

4

More Vista remove lock (remlock) changes

First, a correction to my previous remlock post, where I said that you must still compile your driver as chk before you can see the benefits of the driver verifier’s new remlock checking functionality.  You don’t need a chk version of your driver!  The owner of DV informed me that a fre version of the driver…


INTERFACEs can contain both input and output parameters…and not just function pointers

When you look at the documentation for an INTERFACE and IRP_MN_QUERY_INTERFACE, it mentions that the INTERFACE structure is the input provided to the interface provider (set the by the driver querying for the interface) and the remainder of the interface structure is considered output (set by the driver completing the query interface request). What it…

5

Power relationships in a bus driver

A small but important rule in WDM is that while a PDO is in D0, the parent must be in D0 as well. A very simple statement that can cause a lot of trouble ;). What I have seen is that very few WDM drivers enforce this rule (while KMDF does implement this rule, so…

1