Driver Packages and Drivers- Shall We Disambiguate?

MSDN Logo This was originally a post by Bob Kjelgaard on his MSDN Blog Trouble Ahead- Trouble Behind.   I’m going to repost it here, as it looks like the original content has been removed.
This copy was captured by the Google Cache as it appeared on 31 Jan 2010 21:56:34 GMT.


So you want to know how to sign your driver, eh?  Let us step aside and improve our thinking for a moment, so we can be smarter about what we are asking for- because I don’t think it’s the driver you actually want to sign…

What is a Driver Package?

At a minimum. it is ALL of the files that should be present to make sure your device’s driver and all associated support software installs, begins working, and continues to work when it is plugged in:

  • The driver binaries, including any coinstallers, or other support binaries.
  • The INF file, which tells the OS how to install the “driver” and hook all those things together properly.

You may want more than that in the package- perhaps you have useful value-added utilities to install that you also want on the disk.  Microsoft recommended this in the WinHec 2008 presentation “Creating Deployable Driver Packages for Windows”  (non-Microsoft link)

How do I know what needs to be in the package?

The simplest answer is the best, here- every file listed in the INF as something that needs to be copied is a part of your package, as is the INF and any catalog file (about time I mentioned that) listed in the header.  Telling us you need those files copied means they are a part of the software supporting your hardware.

Why even mention that?  Well, to make things easy for our joint customer- the person who bought your software [and usually your hardware, as well]- we will copy all of those files to a “driver store” on their machine.  Then, if installation needs to happen again (or happens later, as can be the case with a “software first” installation), they won’t need to find your media a second time- everything is already there, and the installation can be very silent [this is a bit of a simplification- if you provide coinstallers, you have options for UI and all kinds of other mayhem that exceed my intended scope- may I suggest perusing some of the WinHec or DDC content?].

Well, as long as we’re looking there- consider getting your driver package on Windows Update, and having it “just work” when the user connects it to their computer…  Look at the presentation before you make assumptions- we may well be willing to let you do a lot more than you think we will…

Could You Get To The Point?

Sure:  You probably don’t want to [or at least don’t really need to] sign your driverYou want to sign the package.

Why?  Because signing protects your customer (and by reflection, you) from tampering and corruption of the entire thing which is signed.  You don’t want someone replacing your coinstaller with one that also installs a keylogger, do you?  Or hiding that logger inside one of your support DLLs?  Or simply modifying your INF to install their malware for them when your driver is installed?  A lot of good it is going to do our customer to have a single driver binary safe and secure when everything else is open to attack.

OK- So How Do I Do This?

A quick summary:

  1. You create a “catalog”, which lists all of the files in your package (except for the catalog itself, of course).
  2. This catalog also has reasonably secure checksums for all of the files at the time they were cataloged.
  3. You then digitally sign the catalog, putting yourself on the line for everything within it, and knowing that if ANY of it gets changed, the change will be noticed.
  4. Now anyone that trusts you can trust your entire package.  Wouldn’t you rather have that than one binary?

This process is often called “catalog signing” as a distinction from “driver signing”- my rant here is that this is a focus on mechanism rather than intent.  Yes, you sign the catalog- but your intent is to vouch for the integrity of the entire package you present.

If you want instructions, you can check here.  But for my testing friends, I’ll promise to show how we roll in WDFQA (that’d be Windows Driver Frameworks Quality Assurance), because signing driver packages is a hurdle you have to clear for agile and reliable test automation when multitudes of drivers are involved.

When do I sign the binary?

The focus here is 64-bit systems.  Of course to me, those are the only ones worth having anymore…

  • If your driver is needed to make the system boot, then you should also sign the binary itself.
  • If your driver is not a WDM driver (yes I happen to have a few of these myself)- or in KMDF parlance- a non-PnP driver, then you may not have an INF.  So again, you should sign the binary.
  • Of course, if you are inclined to sign it anyway, go ahead.  Knock yourself out. No harm done.  Your driver will load somewhat faster on a 64-bit system if you do, so there’s even reasonable benefit to be claimed.  But it isn’t a necessity.

Why I wrote this?  Let’s just say I’ve seen a few too many competent people run afoul of the terminology here and do something less than optimal as a result.  You hear “sign the driver”, so you do, and then you still get all the popups, and have to ask for help you wouldn’t have needed if someone had just given you the right information or asked you to do the right task in the first place.

Bookmark and Share