I have a driver signed with the old cross-sign model with a certificate issued back in 2013. The driver also has a signed timestamp from Dec 2015. This driver has always loaded fine in Win 10 both with or without secure boot.
Now, one customer suddenly reports that two of his new machines, one MSI and one DELL, with secure boot and freshly installed Windows 10, refuse to load this driver (Error 577). If he turns off secure boot the driver loads just fine. On other machines he has tested on, the driver loads with or without secure boot without problems.
I also tried here now to install a fresh copy of Windows 10 on a Hyper-V G2 VM with secure boot active and the driver load fine here as well.
I am clearly missing something. But what could that be? The certificate has recently expired, but since the driver is timestamped that should not be a problem?
He told me that he had come to the conclusion that the problem had something to do with the secure boot keys in the failing machines and sent me some secure boot keys from them. I don’t know where to start with this, though. What are such key files supposed to contain and how do I compare them to anything on a working machine?
I have nothing to offer with regard to your last paragraph, but here are a couple of things which might possibly help, both quite long shots:
The certificate relating to the timestamp server also needs to be verified - is it possible that the new builds can no longer establish a trust path?
Also (and this is a very long shot) it’s possible that UEFI boot might result in tighter enforcement of drivers than BIOS boot. Could that be the difference between the customer’s machines and your VM?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-608920-
xxxxx@lists.osr.com] On Behalf Of xxxxx@ltr-data.se
Sent: 23 May 2016 12:05
To: Windows System Software Devs Interest List
Subject: [ntdev] Win 10 - Driver refuse to load on some machines
I have a driver signed with the old cross-sign model with a certificate
issued back in 2013. The driver also has a signed timestamp from Dec
2015. This driver has always loaded fine in Win 10 both with or without
secure boot.
Now, one customer suddenly reports that two of his new machines, one
MSI and one DELL, with secure boot and freshly installed Windows 10,
refuse to load this driver (Error 577). If he turns off secure boot the
driver loads just fine. On other machines he has tested on, the driver
loads with or without secure boot without problems.
I also tried here now to install a fresh copy of Windows 10 on a Hyper-
V G2 VM with secure boot active and the driver load fine here as well.
I am clearly missing something. But what could that be? The certificate
has recently expired, but since the driver is timestamped that should
not be a problem?
He told me that he had come to the conclusion that the problem had
something to do with the secure boot keys in the failing machines and
sent me some secure boot keys from them. I don’t know where to start
with this, though. What are such key files supposed to contain and how
do I compare them to anything on a working machine?
Hmm… What we’re hearing is that as of Windows Anniversary Edition (RS1), you’ll need an MSFT signature to be able to install your driver… On a NEW install of the OS (that is, not an upgrade).
We haven’t been able to confirm or test this, because we don’t have a single system at OSR that supports secure boot. Can be flattened for testing, and is capable of getting a totally new install.
Have you seen the setup API log from the failing machine? That’d be the first step.
Peter
OSR
@OSRDrivers
Thanks.
Just verified with the customer that he is not installing any preview/insider/etc version of Windows 10, just the latest public release.
This is a legacy driver so there is no PnP style setup. It just gets installed using either a .inf with InstallHInf… etc or using Service Control Manager API along with a user mode application setup package. So there are not many logs that can reveal anything useful, unless I am not missing something here.
I don’t have any UEFI secure boot enabled physical machine around here either and apparently testing on Hyper-V VMs with secure boot is not enough in cases like this. I obviously need to get myself a new physical machine to test this one. If it at all will help me…
Just like David Boyce writes, I also get the feeling that the UEFI secure boot keys somehow need to be part of the trust chain in these cases and that something with the keys of these machines are missing. For instance, OEM might have activated something on these particular models to require some specific level of kernel code verification? I have no idea, I don’t know much about these things.
You can turn on the code integrity ETW tracing and see the kernel code validation events. This gives different info than the PnP setup logs would.
Jan
On 5/23/16, 6:29 AM, “xxxxx@lists.osr.com on behalf of xxxxx@ltr-data.se” wrote:
>This is a legacy driver so there is no PnP style setup. It just gets installed using either a .inf with InstallHInf… etc or using Service Control Manager API along with a user mode application setup package. So there are not many logs that can reveal anything useful, unless I am not missing something here.
>
Cool idea.
You could also ask the customer to disable secure boot and see if that changes anything. As a test, obviously, if they “love” the idea of secure boot.
Peter
OSR
@OSRDrivers
xxxxx@osr.com wrote:
Cool idea.
You could also ask the customer to disable secure boot and see if that changes anything. As a test, obviously, if they “love” the idea of secure boot.
They have confirmed that the driver loads perfectly if they disable
secure boot. On other machines they have, they can keep secure boot
active and the driver loads correctly anyway, just not on these
particular new machines they have recently bought.
I think I’ll give the ETW tracing idea a chance to give us some more
details. Thanks for this idea Jan Bottorff!
–
Olof Lagerkvist
LTR Data - http://ltr-data.se
See the docs at https://msdn.microsoft.com/en-us/library/windows/hardware/ff539911(v=vs.85).aspx for how to enable the ETW code integrity provider and see the logs.
Jan
On 5/23/16, 11:22 AM, “xxxxx@lists.osr.com on behalf of Jan Bottorff” wrote:
>You can turn on the code integrity ETW tracing and see the kernel code validation events. This gives different info than the PnP setup logs would.
>
>Jan
>
>On 5/23/16, 6:29 AM, “xxxxx@lists.osr.com on behalf of xxxxx@ltr-data.se” wrote:
>
>>This is a legacy driver so there is no PnP style setup. It just gets installed using either a .inf with InstallHInf… etc or using Service Control Manager API along with a user mode application setup package. So there are not many logs that can reveal anything useful, unless I am not missing something here.
>>
>
I’ve recently tried to setup a test machine with the DVD iso image of Win10 Preview. The DVD failed to boot because the certificate expired. The machine is an old PC with a legacy bios.
I then decided to boot a WinPE image so to have a command prompt and load the Setup.exe installation program from this command prompt. Setup.exe failed to load because of the file certificate.
I finally decided to download the last evaluation version from MSFT web site and now it’s ok.
So Microsoft guys have put a deadline with a certificate.
I think you should bye a new certificate, build a new package signed with this new certificate and send it to your customer.
These 2 machines could become 100 machines next month.
> I’ve recently tried to setup a test machine with the DVD iso image of Win10 Preview.
The DVD failed to boot because the certificate expired.
All of the preview images have time bombs in them so they will stop working at a particular date. (http://www.pagestart.com/win10tpbuildexp041215.html) All of the pre-RTM Windows 10 previews expired last year, so I imagine that’s what you’ve encountered.
As for the OP’s problem, I agree that the Code Integrity logs are the most useful thing in this circumstance. Also, the results of signtool verify (https://msdn.microsoft.com/en-us/library/windows/hardware/ff553936(v=vs.85).aspx) can be helpful.