Attestation signed driver installable on older Windows Versions? ( 7? )

Hi guys!

You may be able to answer this in no time. I am currently transitioning from an EV signed driver (double signef for W7, Sha1 and Sha256) to an attestation signed driver (because of Secure Boot fun).
Still I need to support Windows 7.

Will I be able to install an attestation signed driver on Windows 7?
Will I have to create 2 installers? One for Windows 10 and one for older versions?
(With the same content, but with different signing?)

Thanks in advance!
Gunther

If you continue to double-sign and get your double-signed driver attestation signed by Microsoft, that will run with a single installer on Windows 7 and up. That’s exactly what we do (although we are doing HLK signing now but we did attestation in the past with double-signing).

Eric

glaure wrote:

Will I be able to install an attestation signed driver on Windows 7?

It depends.  If yours is a PnP install that requires an INF, then the
answer is no.  The attestation process throws out your CAT file and
creates a brand-new one that is marked only for Windows 10.  The driver
would work if you could install it, but you can’t install it because
Device Manager will complain “this driver package was not designed for
this version of Windows.”

If you have a non-PnP install that doesn’t require a driver package,
then you can throw away the CAT file.  The multiply-signed SYS file
should work just fine.

@Tim_Roberts said:
It depends. If yours is a PnP install that requires an INF, then the
answer is no. The attestation process throws out your CAT file and
creates a brand-new one that is marked only for Windows 10.
This also means you always have to have two INF files; One for Windows 10 and one for earlier versions?

Sander wrote:

@Tim_Roberts said:
> It depends.  If yours is a PnP install that requires an INF, then the
> answer is no.  The attestation process throws out your CAT file and
> creates a brand-new one that is marked only for Windows 10.
This also means you always have to have two INF files; One for Windows 10 and one for earlier versions?

Not at all.  The driver package itself can be completely identical.  One
will have a CAT file you created, with your signature and a
cross-certificate.  One will have Microsoft’s CAT file and Microsoft’s
signature.

@Tim_Roberts said:
One will have…One will have…

Why doesn’t Microsoft offer the ability to attestation sign for Windows 7/8? Then we could have a single cat file which everyone wants and keeps asking about. There must be a good reason for this restriction, what is it?

On May 8, 2019, at 10:10 PM, Rourke wrote:
>
> Why doesn’t Microsoft offer the ability to attestation sign for Windows 7/8? Then we could have a single cat file which everyone wants and keeps asking about. There must be a good reason for this restriction, what is it?

Because what they REALLY want is for you to go through HCK/HLK testing and submit the results through WHQL. A package submitted through WHQL can be signed for all Windows systems. Attestation was designed as a quick hack.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

If they wish us to go through WHQL for Win7/8 then why did they drop these from the WHLK?

On May 8, 2019, at 10:41 PM, Rourke wrote:
>
> If they wish us to go through WHQL for Win7/8 then why did they drop these from the WHLK?

You can still request the older systems when submitting the text logs.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Thanks a lot!

FYI:
In parallel I am trying to get the driver through HLK. But thats part of another discussion…

Bye Gunther

You can still request the older systems when submitting the text logs.

You are usually a straight shooter so it is strange you seemed to side step the question. Let’s say it point blank. In order to get Win7/8 through WHQL one must run an old, unsupported, hard to use HCK that requires dedicated hardware, takes an eternity to run, and then also have to run the new WHLK for Win10 in addition to that. This seems completely unrealistic to expect anyone to do this and especially if it is supposed to be a more approved method.

@Tim_Roberts said:
Not at all. The driver package itself can be completely identical. One
will have a CAT file you created, with your signature and a
cross-certificate. One will have Microsoft’s CAT file and Microsoft’s
signature.
This means two driver packages right? So it is no longer possible to have a single driver package for Windows 10 and earlier versions? e.g. it is not possible to select a specific CAT file for a specific OS (only the NTamd64, NTx86, etc decorations exist for the CatalogFile ) from within the INF as is possible with other files referenced within an INF?

As Tim’s response above implies, my comment was incomplete and, yes, what “works for us” does so only because we are signing a non-PNP driver.

Sander wrote:

This means two driver packages right? So it is no longer possible to have a single driver package for Windows 10 and earlier versions? e.g. it is not possible to select a specific CAT file for a specific OS (only the NTamd64, NTx86, etc decorations exist for the CatalogFile ) from within the INF as is possible with other files referenced within an INF?

Let me address your second question first.  The INF allows for
platform-specific CatalogFile entries, but not version-specific. It’s
not clear to me why platform-specific CatalogFile entries would ever be
useful.  If you have one INF for multiple versions, then the CAT file is
going to index all of the files mentioned.  I don’t think there’s
anything to be gained over having one CAT file.

Now, the first question.  **IF** you choose to use the easier
attestation route, then yes, you need two driver packages.  If you go
through WHQL, then you can have a CAT file marked for multiple
versions.  Microsoft wants you to go through WHQL, and that’s the incentive.

Rourke wrote:

You are usually a straight shooter so it is strange you seemed to side step the question. Let’s say it point blank. In order to get Win7/8 through WHQL one must run an old, unsupported, hard to use HCK that requires dedicated hardware, takes an eternity to run, and then also have to run the new WHLK for Win10 in addition to that. This seems completely unrealistic to expect anyone to do this and especially if it is supposed to be a more approved method.

The HCK and HLK have a very steep learning curve, so the first run takes
a while.  But, once you figure it out, it’s pretty much trivial to rerun
the tests for future builds.  This has been the process for decades, so
it’s totally realistic.

This has been the process for decades, so it’s totally realistic.

In addition, most folks who are logo’ing for Win7/8 first did that logo testing back in the Win7/8 timeframe. So, they they remember (and probably still HAVE) the infrastructure. It wasn’t pretty, that’s for sure.

Peter

@Tim_Roberts said:
Now, the first question. IF you choose to use the easier
attestation route, then yes, you need two driver packages. If you go
through WHQL, then you can have a CAT file marked for multiple
versions. Microsoft wants you to go through WHQL, and that’s the incentive.

I think that is the difference (between attestation and WHQL) I was missing. I wrongly assumed the CAT file was always Windows 10 only, but if I understand correctly this is only the case when signed through the attestation route.

Even if you get the old HCK working running it is no automated button press. There is manual processing like the static tools logo test. I also have to think the reason Microsoft is pushing the HCK now is not enough people were running it so there are going to be newbies with no experience in for some big headaches, not just seasoned folks dusting off a familiar legacy they’d love to forget. I am all for excellent driver quality, but dropping support for Win7/8 from the WHLK and forcing people to use the outdated HCK was an own goal hurting both driver quality and best practices because developers are opting for attestation instead of WHQL which in turn discourages the use of inf files which is precisely the opposite direction Microsoft would like people to go.

What we have learned about driver signing in the last decade since Microsoft started experimenting with rules is it hasn’t worked; that’s why they keep changing the rules. And we have learned each time they change the rules it makes things worse hurting the platform, the developer, and the end user. Time to market suffers, our costs go up, and we spend less percentage of our time writing code which hurts our expertise. There is just no telling what they will come up with next but if the past is a predictor of the future, it’s going to be even worse if that’s possible.

There’s almost no statement in your post that I agree with. Let me see… OK! I agree that running the HCK is “no automated button press.” See, we can agree on something.

What we have learned about driver signing in the last decade since Microsoft started experimenting with rules is it hasn’t worked;

Disagree on many fronts.

First, you are conflating drivers signing… introduced with 64-bit Windows and passing the WHQL tests… which has been with us since forever. Two different things, as you well know. So, why muddle your argument and conflate them here?

Driver signing has, in general, turned out to be either a good thing or a pretty neutral thing for the world in general. It makes sense that, in the hostile world in which we find ourselves, the author of a driver should be (reasonably) unambiguously digitally identified. This is what driver signing fundamentally accomplishes. Nothing more, nothing less.

that’s why they keep changing the rules.

You misunderstand how things work up in Redmond. They keep changing the rules to achieve new program goals. Attestation signing is a symptom of the success of the driver singing program; it’s an attempt to tighten the signing requirements, close the loophole in who can get a cert, and (most importantly) get a better handle on what drivers exist in the ecosystem and who’s creating them.

Time to market suffers, our costs go up, and we spend less percentage of our time writing code which hurts our expertise

Drama much? Driver signing does these things? Cuz, you know, I just Attestation Signed two driver packages each with a half-dozen or so components on Thursday and it took, oh (no joke), 20 minutes… max. And that’s counting the time it took me to find and download a proper version of the cursed eToken software (if you want something to complain about, complain about eTokens! THEN we’ll be on arguing on the same side).

Look: If the point you’re trying to make is that driver signing can sometimes be a PITA, I’ll grant you that… with the caveat that it depends on what you’re trying to do. When driver packaging and signing are hard, it’s almost always because (a) you can’t figure out what Redmond wants you to now do, or (b) folks want to create a single set of binaries collected in a single driver package that will install on any platform. In the former case, that’s why we’re all here, sharing our expertise and experience with each other. In the latter case, you’re just making your own life hard. And before you go all “My users are too stupid to select and install the right package” … having multiple driver packages doesn’t imply having multiple installer downloads. Put everything together in a big InstallShield file, and auto-choose which to install and be done with it.

There’s plenty to dislike about how Microsoft are treating driver writers these days. There’s plenty to complain about with regard to how Driver signing has “evolved” over the past several years. But, like the problem of “figuring out what Redmond wants you to do now”, most of these complaints come down to absolutely abominable communication from Microsoft and nothing more. Once you figure out what the fuck they want you to do, it’s usually not so very hard to accomplish what both you and they want. It’s just the figuring that’s senselessly difficult.

Peter

First, you are conflating drivers signing… introduced with 64-bit Windows and passing the WHQL tests… which has been with us since forever. Two different things, as you well know. So, why muddle your argument and conflate them here?

WHQL is a process to satisfy driver signing requirements. I don’t understand your objection of using WHQL to specify a type of driver signing.

Driver signing has, in general, turned out to be either a good thing or a pretty neutral thing for the world in general. It makes sense that, in the hostile world in which we find ourselves, the author of a driver should be (reasonably) unambiguously digitally identified. This is what driver signing fundamentally accomplishes. Nothing more, nothing less.

Looking around it’s hard to see how it changed the world in a positive way. It didn’t stop malicious code. Customers only seem to trust files based on where they get them, not what a file claims to be when you run it. I personally have never, ever got a warm fuzzy feeling by seeing a signed driver dialog pop up box. Like most users, for me it’s just a nuisance box standing in the way of what I want to get done.

and (most importantly) get a better handle on what drivers exist in the ecosystem and who’s creating them.

I hope you are wrong about this. Microsoft could get those metrics in more benign ways without putting handcuffs on every single legitimate developer in the world.

Time to market suffers, our costs go up, and we spend less percentage of our time writing code which hurts our expertise
Drama much? Driver signing does these things? Cuz, you know, I just Attestation Signed two driver packages each with a half-dozen or so components on Thursday and it took, oh (no joke), 20 minutes… max.

Is that a joke? Attestation adding 20 minutes to turning a driver build and you think that’s no big deal? That is INSANE, unnecessary, absurd. Never in the history of driver development has building a driver been so slow. Here we have super fast CPUs and SSDs that sit there doing nothing other than wait for an email response. And you don’t think productivity is impacted.

One more thing about signing hurting time to market, costs, and driver expertise. Let’s use you as a second example. How many discussions have you read or even commented on driver signing? I am guessing over 100, possibly over 1000 because it’s easily become the most discussed topic in drivers. And how has being involved in hundreds or thousands of driver signing discussions improved your driver? And wouldn’t it have been nice if none of these topics ever existed and instead you were involved in hundreds of discussions of real driver development topics? Every driver signing topic that comes up that you waste time on pushes out every future product you will ever make. Time that otherwise could have been used for writing code or participating in meaningful driver discussions is lost. Your drivers could have been better and/or out to market quicker. And let’s not forget you are a savvy and distinguished developer. Driver signing can actually sink the development of a product at legitimate organizations. I would goes as far to say you have been approached for help in such cases.

(b) folks want to create a single set of binaries collected in a single driver package that will install on any platform.

This is another area where Microsoft is completely out of touch with the needs of developers. Microsoft builds operating systems and they don’t understand we want to make one thing that runs on these operating systems, not one thing per operating system. Now it’s even worse as Microsoft wants us to differentiate Windows 10 as a series of different, unique operating systems. It doesn’t matter to our drivers but they make it matter. There are already 8 different Windows 10 variants to worry over and more coming. It’s like roaches spreading.

having multiple driver packages doesn’t imply having multiple installer downloads. Put everything together in a big InstallShield file, and auto-choose which to install and be done with it.

One could (should) do this, but every time I download a software product whether it be from Microsoft or a 3rd party I have to tell it what I will run it on. This is completely absurd. I think it has to do with Microsoft leading the way in this poor usability practice and everyone just follows suit.