Windows 10 Anniversary Update came out at the beginning of August, with plenty of new user-facing features. There were also plenty of changes under the hood as well, including a change in policy regarding how Windows 10 handles device drivers.

When the 64-bit versions of Windows launched over a decade ago, as a security measure Microsoft decided to require that all kernel mode drivers must be signed to be loaded. Under the aptly named cross-signing requirement, hardware vendors would need to get a certificate from one of the major certificate authorities, and use that to sign their drivers. The idea being that by enforcing signing restrictions, it would be much harder for malware to masquerade as legitimate drivers.

This however didn't go quite as well as planned. In particular, malware authors begun stealing driver signing certificates from hardware vendors, allowing them to distribute malware that was for all practical purposes authentic as far as the operating system was concerned. As a result, when Windows 10 initially launched, Microsoft decided to take things one step further and require that not only would kernel mode drivers need to be signed, but that they would need to be WHQL signed by Microsoft.

With that said however, Microsoft's plans hit a snag. There were technical complications to this decision, as well as a problem with the ecosystem being ready for this change. So for Windows 10, WHQL signing was a policy statement and not something that was enforced.

Now with the rollout of the Windows 10 Anniversary Update (version 1607) this policy is no longer just policy, but an enforced requirement: in a fully secure x64 system, all kernel mode drivers must be signed by Microsoft. But, as with all rules, there are exceptions. The new requirement does not affect anyone who has upgraded from a previous build of Windows 10, and therefore it only affects new clean installs of Windows 10 1607. Furthermore the policy is only enforced if Secure Boot is enabled, so for those that require the ability to run traditionally (non-Microsoft) signed kernel mode drivers, one possible work around is to disable Secure Boot. As a backwards compatibility measure, Microsoft is also allowing the installation of drivers signed with end-entity certificates issued before July 29, 2015 which are signed by a supported CA. Finally, to prevent boot issues, boot drivers will not be blocked at this time, but the will be blocked in future versions of Windows.


An example of a warning notice for a driver now blocked under Windows 10 Anniversary Update

Getting to heart of matters then, the additional signing requirements for Windows 10 piqued our curiosity on driver compatibility, and as a result we've gone and taken a quick look at how this change impacts the average user. In practice, it shouldn’t impact very many people at all, as many hardware vendors only ship WHQL (Microsoft signed) drivers to begin with. But there is one particular segment of hardware manufacturers that still semi-regularly release non-WHQL drivers, and that's the GPU vendors. Both AMD and to a lesser extent NVIDIA periodically release beta, hotfix, and other types of drivers that aren't WHQL signed. The obvious question then is raised: will users still be able to run these non-WHQL driver releases under Windows 10 Anniversary Update?

To answer that question, we reached out to both companies for comment, and while only NVIDIA got back to us, they are not too concerned:

"All of our Game-Ready driver releases are fully WHQL certified, so this shouldn’t significantly impact GeForce users at all." - NVIDIA Spokesperson

As NVIDIA only releases the occasional non-WHQL hotfix driver, they are less likely to be impacted to begin with. And indeed, they haven't had a hotfix release since before the release of Windows 10 Anniversary Update. AMD on the other hand has had a couple such releases, so we decided to simply see what would happen if you installed a non-WHQL driver release on a Secure Boot enabled system.

As it turns out, even AMD driver releases marked as non-WHQL are still sent to Microsoft for signing. And as a result they install on Windows 10 Anniversary Update just fine. Now to be technically accurate, AMD could always ship an unsigned driver if they deem it necessary. But as we can see, some thought has been put into this, and the company isn't releasing any drivers that won't install under Windows 10 Anniversary Update. Nor, do I expect that NVIDIA would ship unsigned hotfix drivers either.

The net impact to the average user then is essentially zero. Having drivers that are signed by Microsoft but not fully WHQL does blur the line between what is and isn't really WHQL. But because all drivers are being signed regardless of WHQL status, it means that non-WHQL drivers are just as usable under Windows 10 Anniversary Update as they were before with the original release of Windows 10. This, ultimately, was the conclusion we expected to find. But it's nice to be able to confirm what we've already suspected.

Source: Microsoft Hardware Certification Blog

POST A COMMENT

85 Comments

View All Comments

  • Alexvrb - Saturday, October 15, 2016 - link

    Just disable secure boot on those machines. They're still more secure than 7 even without it. Reply
  • Samus - Sunday, October 16, 2016 - link

    Yep. Good point, I don't think people realize how easy Windows 7 can be hijacked with a driver-based rootkit, even with secure boot (because windows 7 drivers under secure boot only validates the drivers that load during the boot process, not drivers initialized under the operating environment like occasional drivers)

    Windows 10 and even Windows 8 introduced a internally validating driver model which although it can be bypassed, at least gives you a scary warning you need to click through TWICE.
    Reply
  • nathanddrews - Friday, October 14, 2016 - link

    While I appreciate Microsoft's concern, I frequently run unsupported drivers and software for some things. IMO, it should be an option on the UAC panel.

    Typo in article title:
    "Enforcesment Policy" should be "Enforcement Policy"
    Reply
  • BrokenCrayons - Friday, October 14, 2016 - link

    "...a fully secure x64 system..." Color me skeptical (and yes, you can use a crayon for that). Reply
  • extide - Friday, October 14, 2016 - link

    While I agree with what you are saying, I think the comment was made more in terms of an x64 system with all of the available security options enabled. Reply
  • Senti - Friday, October 14, 2016 - link

    Driver signing enforcement to combat malware? Don't make me laugh. Only idiots actually believe that. Malware is spreading through bugs in existing fully signed components.

    The actual purpose of this policy is enforcing media DRM and attempts to create a fully walled garden. Users get only drawbacks, like you can't easily patch a certain driver even if you have administrator rights (one well known example is Realtek audio drivers).
    Reply
  • Gigaplex - Friday, October 14, 2016 - link

    The malware may spread through bugs in signed components, but signing enforcement helps reduce the impact once the malware is on the machine. It makes it harder for the malware to escalate privileges or install root kit drivers. Reply
  • Senti - Saturday, October 15, 2016 - link

    It does not. If you got in the system through bug in signed driver you are basically have exactly the same rights as that driver. Instead of installing your code "the official way" you just call the compromised signed driver to execute it. Reply
  • Klimax - Saturday, October 15, 2016 - link

    DRM is already long ago enforced through Protected Media Path. Don't think anybody managed to brake it even with kernel-mode drivers.

    As for malware, see rootkits and associated fun. And look up Sony Rootkit fiasco...
    Reply
  • Senti - Saturday, October 15, 2016 - link

    I don't know the situation with PMP, but if nobody broke it just means it wasn't interesting enough. The whole thing was invented for protecting BD playback while people found better ways to dump it.

    "Rootkit" is just a technique, it has nothing to do with signing enforcement. Actually Sony is likely to get with no problems WHQL or any other signature on it from MS if it would be required.
    Reply

Log in

Don't have an account? Sign up now