pci.sys upper filter driver HLK PnP remove device test problems

NTDEV
1

Hi,

I need to be able to read (and never write) any PCI config space for our endpoint protection product. To do this, I implemented a filter driver sitting above pci.sys that uses a PCI bus interface standard interface. To get my driver signed I want to submit it using the Microsoft Partner Center.

Unfortunately my driver fails the HLK PnP Remove Device tests. Now I have ran those tests on pci.sys and they fail, too. It looks like my driver stack can’t be removed, or am I wrong there? Do you have any suggestions about what I could do? Thank you in advance for your time.

2

And you already KNOW that you don’t need to pass the HLKs to get your driver signed, right? Cuz, “attestation signing”??

But you still want to pass those HLKs?

Juuuuust checking,

Peter

1 Like
3

You generally cannot remove a pnp bus filter driver as the bus device FDO
also cannot be removed. You should be able to work around this if you
really need to get WHQL signed rather than attestation signed.

Mark Roddy

4

@“Peter_Viscarola_(OSR)”
Hmm seems like I misunderstood something? How do I get my driver signed without passing all HLKs ?

@Mark_Roddy
Thank you for confirming my suspicion. I thought that working around it just to pass the HLK wouldn’t be good style and shouldn’t be necessary b/c the HLK remove tests are just not really suited to this kind of scenario. Anyhow, could you give me a pointer to how such a workaround could look like? Just out of curiosity…

5

How do I get my driver signed without passing all HLKs ?

There’s something called “Attestation Signing” – See my blog post from 4 years ago here. And the MSFT doc page about it here.

I think it’s time for me to write another summary of all the signing options for folks.

Peter

6

Thank you. Yes it gets really confusing… I spent days reading MS docs and it gradually confused me more and more

7

If you don’t do this (driver development) every day, it can be hard to separate truth from fiction.

Sadly, MSFT seem to at least partially foster the presence of disinformation to “encourage” more folks to pass the HLKs. I’ve been trying to get all the places where it says “Attestation signing does not work for Windows Server” for YEARS. I mean, literally, years. The doc writers are “happy” to remove the offending language when I file a bug. Eager even. But it seems I have to search and destroy every, single, specific, instance where this policy is incorrectly cited. Arrrrgh.

So, in very brief summary:

  • Win10: Attestation Signing works for both client and server SKUs.
  • Win 7 SP1, non-PnP drivers: If you have a non-PnP driver, that same Win 10 Attestation signed driver package will allow your driver to be installed on Windows 7. Be sure (a) to NOT sign the driver executable yourself before submitting it (out of the box Win 7 SP1 systems seem to only understand the first signature on the executable) and (b) be sure KB4474419 is installed.
  • Win 7 SP1, PnP drivers: Your Win 10 Attestation signed package will work (same caveats as above about not first signing with your own signature and ensuring the KB is installed) however… during the install process the user will be treated to a pop-up saying “This driver is not digitally signed!” – If they ignore it (and the subsequent scary red popup saying “Windows can’t verify the publisher of this driver software") the driver will be installed without error.
  • Win 8.1, non-PnP Drivers: The driver package that you Attestation signed for Win 10 will work fine.
  • Win 8.1, PnP Drivers: You’re out of luck, unless you pass the WHQL tests.

To ensure compatibility with Win7, we recommend that you do not sign any of the executables in your driver package prior to submitting them for Attestation Signing (or any type of signing, actually). When you get the signed driver package back, we recommend that you then sign all the executables in the driver package with your company’s cert (don’t forget to use the “/as” option in signtool when you do this, to cause your signature to add to and not replace the MSFT signature). Please don’t ignore signing the executables… it’s one way to ensure your end-users know where the driver originated (and, of course, never forget to list your company name in the Resources, so it can be clearly seen in the Details tab).

Of course, in all cases, you can always pass the WHQL tests… which is a “best practice” in any case but not always realistic or even possible.

I know the colleagues here will correct/update anything I may have gotten wrong above… but I DO believe that’s the most up-to-date info.

Peter

(Edited about sixty five times to add more info and clarity each time)

2 Likes