I guess I touched a nerve…Vista driver signing requirements

This post seems to have touched some raw nerves.  I wasn't expecting that but I'm not surprised either given all the feedback I've heard re: driver signing since the first beta of XP.   I understand the frustrations, I also know that when Windows crashes it is usually because of a 3rd part kernel mode driver.  Who gets the blame from the user though?  Microsoft.  Who takes the support call?  Microsoft.  Microsoft has a vested interest in ensuring that 3rd part kernel mode code is not going to crash systems and that when it does we can track down the 3rd party and resolve the problem.

From reading the comments it appears a couple of things are not getting communicated clearly enough.

Will Dean: "*Requiring* WHQL signing would be one of the worst decisions MS ever made. Nobody who has EVER worked *outside* MS developing peripherals or drivers would support this. Acheiving WHQL signing is difficult, slow, expensive, and backed by an extremely poorly documented test suite which rarely does the same thing twice, and rarely fails because of the thing you're testing."

Actually, WHQL signing is not required, nor is using the test suite.  The requirement is that all x64 kernel mode drivers be signed with a PIC.  The PIC is issued by Microsoft but has nothing to do with WHQL.  From the whitepaper....

"A signed driver package must have a signed Microsoft Authenticode® catalog (.cat) file. This file contains a digital certificate that identifies the origin of the package plus hashes of the contents of the package that allow the system to verify that it has not been altered. A signed .cat file can be obtained in one of two ways:

·         Obtain a Windows logo. Drivers that pass WHQL testing for the Windows Logo Program receive a .cat file that is signed during the WHQL submission process.

For information about the Windows Logo Program, see “Resources” at the end of this paper.

·         Obtain a PIC and use it to create a signed .cat file. PICs are issued by Microsoft and can be used to sign kernel-mode modules that are intended for Windows Vista. The PIC verifies the integrity and origin of a driver. To be signed with a PIC, drivers are not required to pass WHQL testing."


Norman: "I would rather manipulate the registry or whatever, using known programmatic techniques, instead of pushing buttons on a dialog that was designed to be seen. I've been shafted twice by automatic button pushers."


The unsigned driver dialog is really not relevent to this discussion.  The important change is that it will be impossible to load unsigned kernel mode drivers in Vista x64 systems.  From the whitepaper..."Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services."


SiM: "Drivers DigSig is generally good move with one exception: currently it _requires_ Verisign certificate and so establishes Verisign monopoly."


Good point.  This part is really just policy however.  I could see it changing, especially if you give feedback to the right people.






Comments (4)
  1. Rosyna says:

    How would this improve the situation of MS getting blamed? Especially since there are no tests required to be signed. Not that the tests ensure any kind of stability in the code.

    (And trust me, I know a thing or two about getting blamed for things).

  2. Norman Diamond says:

    > I also know that when Windows crashes it is

    > usually because of a 3rd part kernel mode

    > driver.

    Then you know wrong. The number of Microsoft-provided Microsoft-self-signed drivers that have given me BSODs is larger than the number of third-party kernel mode drivers that have given me BSODs.

    The two third-party kernel mode drivers that have given me BSODs include one signed by WHQL and one that was not signed. The one that wasn’t signed, I didn’t even know was present because its installer had programmatically pushed buttons while hiding them. Unfortunately I made the mistake of blaming Microsoft for the one I didn’t know was there, because I thought it was Microsoft’s floppy disk driver. The fact turned out to be that Microsoft’s drivers do still handle floppy disks a lot better than they handle hard disks.

    Microsoft-provided Microsoft-self-signed drivers that have given me BSODs include at least two video drivers, PCMCIA.SYS, NTFS.SYS, a forgotten name involved in TCP/IP in Windows 2000, a forgotten name involved in ActiveSync, and almost surely at least two more.

    Oh sorry, I forgot one more unsigned driver that also gave me BSODs. But I knew that one was there, I knew BSODs were likely, and I was running it in a crash box. Never had time to finish writing it because paying customers get priority, but I did get it past the BSOD’ing stage. Meanwhile, notice how lucky it was that I wasn’t trying to develop this driver on Vista x64. I’d never even be able to get it installed to test it.

  3. Will Dean says:

    I have read the whitepaper, and I know it’s only requiring the Verisign monopoly payment, not the MS one.

    However, as I said in my comment, I was really replying to Tripp’s post, which *does* advocate mandating WHQL and requests feedback, though his blog doesn’t allow comments.

    I’ll say again, I do not believe that anyone who has faced WHQL signing from outside MS (or perhaps its ‘partners’, whoever they are) would relish making that process mandatory. (Of course, you couldn’t *actually* do that, because then no one could develop a driver in the first place.)

    The real tragedy of driver-related BSODs is that in many applications people should never have needed to write KM code at all, let alone the ghastly 50 lines of application code surrounded by 5000 lines of impossible PnP/Power boilerplate.

    Hopefully WDF is going someway towards fixing this – I have read somewhere that it needed 100 states in its PnP/Power IRP handling code to actually get it right. Many authorities seem to have come to the conclusion that it’s actually impossible for the rest of us to do this stuff right, which is why it’s so irksome to be threatened with mandatory signing.

    I am 100% clear that, when I discuss what’s involved in WHQL-signing with my clients, the details make them *hate* MS. The poor documentation, the monopoly fees, the opaque test suite, the bizarre test hardware requirements (go on then, run out and buy some ‘USB loudspeakers’ this lunchtime), the ‘send umpteen devices to MS’ (for a $250000 instrument? I don’t think so!) stuff is horrible. The feeling that one’s being put through this by the arm-twisting school bully is particularly loathsome.

    I often suspect that people inside MS have only the vaguest idea what it’s like outside. This issue (and views like Tripp’s) demonstrates this SO clearly.

Comments are closed.

Skip to main content