Just read through the Windows driver news. Microsoft will slowly block kernel drivers from the older Microsoft Trusted Root Program. So far so good.
It reads that only WHCP signed drivers will eventually be loaded in the not so far future.
But what does this mean for Attestation signing? Will Attestation signed drivers still be loaded? No single word about that.
Can someone enlighten us?
Yeah it doesn’t address attestation signed drivers at all, so who knows?
on the other hand this is a nightmare for the many legacy hardware devices and their drivers that are installed and running with zero problems and absolutely no good reason to be updated.
Another big ass churn by MSFT that will push more small companies out of the windows market.
Yes, that’s a poorly written post lacking in exactly the critical information we need.
It starts with
the removal of trust for all kernel drivers signed by the deprecated cross-signed root program.
and then immediately says
Microsoft will maintain an explicit allow list of reputable drivers signed by the cross-signed program.
So, not all cross-signed drivers then. (Unless “removal of trust” has a very specific meaning here which isn’t clear to me.) Will there be a list/XML file (similar to the Vulnerable Driver Blocklist) that we can consult to determine which of our hundreds of drivers will break? Do we have to go install every single driver we own in the Audit mode and then, say, go consult CodeIntegrity logs to see if they run afoul? (This is suggested in user comments below the article.) Are these checks on a per-driver-version basis, like the Vulnerable Driver Blocklist, or is it a general “this driver is cool?” (I assume the former, but it would be nice to know.
But, yeah, the big elephant in the room is whether Attested Signing will continue. There’s a lot of WLK talk in the article, but if just “cross-signed drivers” is the issue I’d expect Attested Signed drivers will continue to function. Whether we’ll be able to continue to use Attested Signing in the future is the big question. If not, we need to understand that ASAP.
There’s nothing immediate for attestation drivers, although we are looking into how we could have everything require the HLK.
Thank you very much for your feedback about attestation signing, much appreciated!
According to this article (from Peter from OSR) not every driver does fit / can pass HLK.
Also keep in mind that some companies have a rather small audience with only a few hundert to a thousand customers, for them HLK testing (if actually possible for their drivers) is another burden.
Please keep attestation signing as an option alive.
Same, please keep attestation signing as an option. I understand why the HLK is important, but it’s not always viable for small/individual developers.
Custom kernel signers looks like an attempt to address this, but it’s insufficient since customers can’t onboard their existing systems at all (have to reset Windows to provision).
I would also like to advocate for retaining the attestation signing. I’m maintaining a driver for specific PCI cards for many years now. The driver mainly uses IOCTLs to send data to and read data from specific PCI cards, and not many changes to the driver skeleton were required over many years and across many Windows versions.
There was not a single problem report due to this driver, but having to do full HLK tests to le the driver be signed would be a huge amount more of efforts.
I don’t have specifics to share at this time, but I agree that requiring all drivers to pass the current HLK would be unreasonable
At this point, requiring access to the partner dashboard and the hardware testing portal is unreasonable. Somebody at MSFT ought to fix that mess.
I could not agree more.