Kernel Mustard

Jennifer Stepler spent some time whiteboarding at the MVP summit about signing. She was explaining that there are two different kinds of signing in the Windows world: Device Installer signing and Code Security Signing. Here are her notes:

In search-engine-findable text:

• DMI [device management & installation] -> .cat file
• Install Time
• 32 & 64-bit
• Unsigned Driver pop-up
  • Unsigned
  • Signed by untrusted cert
• Signed-by pop-up – signed by trusted cert
• Just [silently] install
  • Built in Windows build lab
  • WHQL logo signature
  • Trusted cert from trusted publisher

Example of trusted cert path: MS root -> Verisign -> ATI

Kernel Mode Security Signing

• 64-bit
• Untrusted binary will not load
• Signed with cert that roots to MS root authority
• MS signs:
  • Windows build lab
  • WHQL
  • MS products
• Cross-sign with trusted cert & MS cross-cert
• CAT file (signed & loaded in CatDB) or the binaries

These notes resulted from about an hour of discussion, so they’re missing a lot of detail.

A common misconception in the driver-signing world is that boot-start drivers must have a signature embedded in the driver binary itself. This is not strictly true, although it’s still the right thing to do.

To re-cap, x64 systems check every kernel-mode binary on load for a digital signature. The signature can be an Authenticode signature or a Microsoft-supplied signature, as I discussed in my last post.

There are actually two ways that the OS can tell if a driver is signed:

1. The driver binary can be signed, as a resource embedded right in the PE file
2. The driver’s .cat file can be signed

The boot loader can, in fact, handle either type of signature, but for important performance reasons, signing the binary itself is the recommended practice. Peter Brundrett from Microsoft was kind enough to provide this explanation:

The loader does have code to find .cat files for boot start drivers. However, the loader depends on a simple I/O subsystem that is not very high performance. If a boot start driver is catalog signed, the loader has to locate (seek and read) through potentially hundreds of small catalog files to find the catalog that signed the particular boot start driver. There is mechanism in code integrity in the loader to be smarter about how it locates the catalog that did sign the boot start driver on the next boot. But using embedded signatures is much better, and over time as more update catalogs are installed, makes for more consistently faster boot times that do not have catalog dependencies.

So, again, the best practice is simply to sign every binary you produce. It’s easy to integrate into the build system and will keep you from having to ever think about this stuff again.

We had some extended discussion at the MVP summit on the topic of driver signing. Jennifer Stepler from the WDK team spent a couple of hours talking through the various kinds of signing and clearing up the confusion.

To recap, there are two kinds of signing used in the [Windows] world today: code signing and device installation signing. Code signing means embedding a digital signature in your compiled binary, such as a .sys file. These signatures are checked by the loader and (on x64) your driver will not load if it’s not signed in this way. Notice that this happens at load time, which is every time PnP decides to fire up your driver (i.e. every boot, plus immediately after install time).

The other type of signing is device installation signing. The device manager checks for signatures in .cat files that go with your driver package. To sign a .cat file, you first have to generate one, and then sign it with signtool. This signature allows the device to be installed without the big nasty unsigned driver warning. There are two kinds of signatures that you can put on a driver package: you can get your driver signed by WHQL, or you can sign your driver package with your own code signing certificate, similar to other code (called an Authenticode signature). If you use an Authenticode signature, the user will get a friendly “Do you want to install software from XYZ Corp?” prompt, with an option to always trust this publisher from now on. If you use a WHQL signature, the installation is totally silent.

It is Microsoft’s recommendation to use both kinds of signatures on all drivers, x86 or x64.

Don Burn pointed out on NTDEV today that there is a new DTM newsgroup: microsoft.public.development.device.drivers.dtm. Microsoft had gotten some negative feedback from the driver dev community, myself included, over DTM-related communications. Hopefully this will be a useful new forum.

Someone recently referred to Driver Test Manager as A lunatic’s nightmare on NTDEV. Not many people like it, it seems. That’s really too bad; a lot of work went into it, and when I first saw it a couple of years ago at the last MVP summit, I was really impressed – it looked like something we could really use in automating our QA, beyond simply testing for WHQL. Alas, that vision hasn’t come to life for us yet, but consider me an optimist – I still have hope for DTM as something more than just a pain in driver devs’ necks.