Windows Server 2016 (vNext) driver signing

As you might know, some time ago Microsoft announced that every kernel
driver for the Windows Server 2016 (vNext) must pass the HLK certification.
This information is available in the OSR blogs here:

Questions and Answers: Windows 10 Driver Signing
https://www.osr.com/blog/2015/07/24/questions-answers-windows-10-driver-signing/

Driver Signing ? More Details Emerge
https://www.osr.com/blog/2016/06/02/driver-signing-details-emerge/

But i can’t find any mentions about this in the Microsoft official
documentation pages. For example:

Driver Signing Policy
https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-

Driver Signing changes in Windows 10
https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/04/01/driver-signing-changes-in-windows-10/

Driver Signing changes in Windows 10, version 1607
https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

Moreover, in my test environment with Windows Server 2016 (14393.0.160715-
1616.RS1, 180 days evaluation) the attestation-signed drivers are working fine,
even with Secure Boot enabled.

So, my questions are:

  1. Whether passing HLK tests is really necessary for Windows Server 2016?

Offtop:
May be Microsoft forgot about their driver signing policy? :slight_smile:
May be the policy enforcement delayed again, as for Windows 10 RTM-RS1?

  1. If yes, where to find detailed information about a signing process and
    about hardware & software requirements?

Thanks.

I signed a driver today with a Verisign cert and the cross certificate, and it loaded on that exact Server 2016 build, which I strongly believe is the production release, secure boot was off. It did give the well known do you trust this driver from xxx dialog, and I said yes, and it installed. Testsigning was off.

Jan

On 9/30/16, 12:36 AM, “xxxxx@lists.osr.com on behalf of xxxxx@mail.ru” wrote:

Moreover, in my test environment with Windows Server 2016 (14393.0.160715-
1616.RS1, 180 days evaluation) the attestation-signed drivers are working fine,
even with Secure Boot enabled.

Was your certificate issued before jul 29 2016?

Sorry, I meant before jul 29 2015.

No, the certificate was issued 6/7/2016 and uses sha256 but is not stored on a hardware token. It must work because secure boot is off. If I get a chance next week, I’ll turn on secure boot and see what happens. The OS is installed as UEFI boot.

Jan


From: xxxxx@lists.osr.com on behalf of xxxxx@gastecnologia.com.br
Sent: Friday, September 30, 2016 9:37:06 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Windows Server 2016 (vNext) driver signing

Sorry, I meant before jul 29 2015.


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

Sigh.

We haven’t said/written anything more on this topic (the official policy on Server 2016 Driver Signing), because we haven’t heard anything definitive that we can share and – once again – the community is left guessing.

To be safe, I’d run/pass the HCKs if you can and sign your driver’s that way. This lets you sign your package for down-level OSes as well.

If you have problems passing the HCKs (passing the HLKs for most device drivers and filters is pretty fundamental, so you should just shut up and do it… but for certain types of file systems and filters it can be a really onerous task that does not necessarily reflect the underlying quality or reliability of the driver under test) it’s looking to us like attestation signed drivers work on Server 2016.

Peter
OSR
@OSRDrivers

The fact that one has to run both the HCK and HLK, and that the test suites
each have their own issues and requirements, is a real pain in the ass.
Depending on what type of device you are testing the cost may be high
enough to cause developers to defer non-critical bug fixes and feature
development for currently signed drivers. The test suites reflect an
earlier era when release cycles were annual or longer. These days many
organizations are working within either a continuous release process or a
short (quarterly) release cycle. The qualification tests should take hours,
not days to run.

Mark Roddy

On Sat, Oct 1, 2016 at 8:40 AM, wrote:

> Sigh.
>
> We haven’t said/written anything more on this topic (the official policy
> on Server 2016 Driver Signing), because we haven’t heard anything
> definitive that we can share and – once again – the community is left
> guessing.
>
> To be safe, I’d run/pass the HCKs if you can and sign your driver’s that
> way. This lets you sign your package for down-level OSes as well.
>
> If you have problems passing the HCKs (passing the HLKs for most device
> drivers and filters is pretty fundamental, so you should just shut up and
> do it… but for certain types of file systems and filters it can be a
> really onerous task that does not necessarily reflect the underlying
> quality or reliability of the driver under test) it’s looking to us like
> attestation signed drivers work on Server 2016.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

I’d agree with every word above posted by Mr. Roddy.

Peter
OSR
@OSRDrivers

xxxxx@mail.ru wrote:

Moreover, in my test environment with Windows Server 2016 (14393.0.160715-
1616.RS1, 180 days evaluation) the attestation-signed drivers are working fine,
even with Secure Boot enabled.

I’ll just add confirmation that I’m seeing the same result you
describe here, too.

I had actually been unaware until seeing your post that a 14393 build
of Windows Server was even available. It’s not posted in MSDN
Subscriptions yet, but is available as 180-day eval you mention from
https://www.microsoft.com/evalcenter/evaluate-windows-server-2016.

On the Server 2016 14393 build, even with current Windows Updates as
of October 3, 2016, our Windows 10 attestation-signed drivers are
loading successfully, even with a clean non-upgrade installation and
Secure Boot enabled.

The attestation signing was done by selecting both the “Windows 10
1506 & 1511” as well as “Windows 10 1607” platforms during submission.
The binary files are dual-signed with our SHA256 EV certificate issued
August 2015 too, for the record.

Our .INF is for a “NetClient”-class device with software-only drivers,
which may factor into the equation as well. This same driver package
did run into the new Windows 10 1607 behavior with Secure Boot
enabled, and was rejected on clean non-upgrade installations of that
platform until we started performing the attestation signing.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com

Just thought I’d throw in that I’m seeing the same here.

Here are the only published items I could find that outline the policy:


https://msdn.microsoft.com/en-us/windows/hardware/drivers/develop/attestation-signing-a-kernel-driver-for-public-release?f=255&MSPPError=-2147217396

“An attestation signed driver will only work for Windows 10 Desktop, it will not work for other versions of Windows, such as Windows Server 2016, Windows 8.1, or Windows 7.”

https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887(v=vs.85).aspx

“An attestation signed driver will only work for Windows 10 Desktop; it will not work for other versions of Windows, such as Windows Server 2016, Windows 8.1, or Windows 7.

The dashboard will not accept attested device and filter driver signing submissions for Windows Server 2016.

Windows Server 2016 will only load dashboard signed drivers that have successfully passed the HLK tests.”


It looks like most of those statements are currently false.

The HCK and HLK test environment is TERRIBLE for continuous integration. It’s enough of a pain to have to maintain a dedicated test fixture for the variety of hardware we need to test. It makes it considerably worse when you have to hand bake all the automation to start a test remotely.

Marks comments are spot on. We don’t have THAT many devices and drivers that we maintain, but man is it a PITA. I would love to see how those folks like Intel (or even Microsoft) manage their build, test, sign, release effort.

I remember that the Windows Server 2016 drivers signing policy would follow the same Windows 10 exceptions as outlined here https://www.osr.com/blog/2016/06/02/driver-signing-details-emerge/.
However, I couldn’t find anywhere this explicitly told from Microsoft, only for Windows 10.