Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Upcoming OSR Seminars:

Writing WDF Drivers I: Core Concepts, Nashua, NH 15-19 May, 2017
Writing WDF Drivers II: Advanced Implementation Tech., Nashua, NH 23-26 May, 2017
Kernel Debugging and Crash Analysis, Dulles, VA 26-30 June, 2017
Windows Internals & Software Driver Development, Nashua, NH 24-28 July, 2017


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 7  
10 Aug 17 15:58
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 41
Attested signing not required when using inbox driver?

We have an INF that references usbser.sys and nothing else. I was surprised to find that by simply signing its CAT file in the traditional manner that it loaded fine on Windows 10 with Secure Boot enabled, no attested signing or WHQL required. Is this documented/expected behavior?
  Message 2 of 7  
10 Aug 17 19:34
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11570
Attested signing not required when using inbox driver?

xxxxx@ni.com xxxxx@lists.osr.com wrote: > We have an INF that references usbser.sys and nothing else. I was surprised to find that by simply signing its CAT file in the traditional manner that it loaded fine on Windows 10 with Secure Boot enabled, no attested signing or WHQL required. Is this documented/expected behavior? It depends. The strict signing requirement only applies to new installations. If you have upgraded from the original Windows 10 release, then the attestation requirement does not apply. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 3 of 7  
11 Aug 17 09:26
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 41
Attested signing not required when using inbox driver?

> It depends. The strict signing requirement only applies to new installations. If you have upgraded > from the original Windows 10 release, then the attestation requirement does not apply. Yeah, this setup should enforce all the rules: It is Anniversary Update, installed completely clean, Secure Boot enabled. "Normal" driver packages (with a .cat, .inf, and .sys) require Microsoft's signature on this system, but packages containing only a .cat and .inf do not. In the original posting I used the term "inbox driver" because my current example is using usbser.sys, but it could be any INF referencing a driver not installed by that INF. We have a package that installs a third-party driver, and we have other INFs that reference that driver. If we generate a CAT for one of those INFs and sign it internally, it installs without a hitch, no Microsoft signature needed.
  Message 4 of 7  
11 Aug 17 13:32
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11570
Attested signing not required when using inbox driver?

xxxxx@ni.com xxxxx@lists.osr.com wrote: > > Yeah, this setup should enforce all the rules: It is Anniversary Update, installed completely clean, Secure Boot enabled. "Normal" driver packages (with a .cat, .inf, and .sys) require Microsoft's signature on this system, but packages containing only a .cat and .inf do not. > > In the original posting I used the term "inbox driver" because my current example is using usbser.sys, but it could be any INF referencing a driver not installed by that INF. We have a package that installs a third-party driver, and we have other INFs that reference that driver. If we generate a CAT for one of those INFs and sign it internally, it installs without a hitch, no Microsoft signature needed. Is this a PnP package? If you're doing a [DefaultInstall] installation, then it's not PnP and the CAT file is irrelevant Assuming it's PnP, all I can say is that it's not supposed to work that way. As I understand it, on a machine with the "extreme vetting", with a PnP package, it checks the CAT file at install time, and it checks the SYS file OR the CAT file at run time. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 5 of 7  
15 Aug 17 16:40
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5916
List Moderator
Attested signing not required when using inbox driver?

Anniversary, so RS2, I guess. And you were careful to say you did a clean install. For sure, the ability to load a driver that's cross-signed but not MSFT signed, is neither documented nor expected behavior on new installations of RS2 or later, IF SecureBoot has been enabled. <quote> but packages containing only a .cat and .inf do not. </quote> Because the SYS being loaded is MSFT signed? I wonder... Peter OSR @OSRDrivers
  Message 6 of 7  
16 Aug 17 15:53
Gabe Jones
xxxxxx@ni.com
Join Date: 19 Mar 2012
Posts To This List: 41
Attested signing not required when using inbox driver?

> Anniversary, so RS2, I guess. And you were careful to say you did a clean install. Yes. Just to make sure, I've also attempted to install a standard driver package (inf & sys included) signed locally with a current certificate. This failed due to the more stringent checks. That same driver signed via attestation installs & loads fine. > Because the SYS being loaded is MSFT signed? I wonder... That is my suspicion as well. I thought it would fail at install time (.cat for the INF is only signed by our certificate, not by MS), but it did not, and after the install succeeds the actual driver is indeed MS-signed, so it loads just fine. I really like this behavior (it assists greatly in a number of customer scenarios with our products), but I just wasn't sure if we could rely on it.
  Message 7 of 7  
16 Aug 17 16:29
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5916
List Moderator
Attested signing not required when using inbox driver?

Any time the conversation turns to driver signing, my head hurts. I spend half my time on this topic telling people "No, no... it really is straight forward" and I spend the OTHER half of my time on this topic telling DIFFERENT people "No, no... it's not nearly as simple as you think." I had a conversation with a very senior (and helpful) PM type at MSFT recently, who made it all very simple: 1. All x64 kernel-mode modules needs to be signed 2. The necessary signing is "sign and cross-sign" 3. EXCEPT if Secure Boot is enabled, THEN the signing needs to be by MSFT. That IS simple. And that IS correct. And that IS enough for at least 75% of the people who author kernel modules. It just doesn't account for (a) the details, (b) the exceptions. ;-) Did I mention that my head hurts? Peter OSR @OSRDrivers
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 15:38.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license