Wow… a LOT of questions.
I use “sc create” to install the module so I can not specify things via the inf file
That is a mistake. Create an INF file. That’s the proper way to install any driver, including non-PnP drivers.
it is accessed using CreateFile using such a string “\?\GLOBALROOT\Device\myDevice”
Hmmmm… yeah… that’s not “the right way” to do things. You’re basically violating Windows layering there.
Why would I want a symbolic link? It just looks like an extra, unnecessary step that imposes restrictions on my name.
Well, no. It doesn’t impose any “restrictions” on your name.
Windows differentiates between internal device names and device names that are exported for easy access to user-mode apps.
As you would no doubt learned from the article to which I pointed you, “best practice” is to not name the FDO… this applies equally to FDOs created by your Filter Driver (what some people – not me – call Filter Device Objects or FiDOs). The symbolic link points to the PDO (as you know from the article) and thus you have a single point of protection for the devnode.
I specify the system device class because it looks like my device belongs there
But it probably doesn’t… According to the docs: “This class includes HALs, system buses, system bridges, the system ACPI driver, and the system volume manager driver.”
Your blog post is very detailed about PDOs and FDOs, I am a filter driver, though.
Your Device Object is considered an FDO for this purpose.
What difference does the interface GUID do?
It’s a way for user-mode apps to locate devices by INTERFACE CONTRACT as opposed to by name. It also has the (rather wonderful) advantage of allowing users (both user-mode and kernel-mode) to register callbacks so that they can be informed of the arrival or departure of a given Device Interface by GUID.
I still do not understand why it is best practice to not expose my upper filter driver to user space.
As you no doubt understand, unless you’re creating a separate, out-of-stack, Control Device Object (which is, in fact, best practice for sending Requests to your filter)… if the device you’re filtering has more restrictive access than the access that you’re provided for your Filter’s Device Object, you’re changing the protection that’s allowed on the dev node to be less restrictive. Somebody could open your device, which is layered above the (pre-existing) FDO and PDO and send Requests…
Again, the RIGHT solution here, if you want to provide command/control operations on your filter, is to create a separate Device object, called a “Control Device Object” that’s outside the stack that you’re filtering.
Why is it dangerous if my filter driver exposes a name that could be used to access the pci express root complex?
Because… ah… somebody who shouldn’t be accessing the PCI Express Root Complex might access it??
There are Bad People in the world, you know.
3b) If I do the two driver construct,
I don’t know what this means.
Hope that helps,
Peter
