Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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

glaureglaure Member Posts: 8

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

Comments

  • Eric_BergeEric_Berge Member Posts: 32

    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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,063
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

  • SanderSander Member Posts: 10

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,063
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

  • RourkeRourke Member Posts: 37

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,063
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • RourkeRourke Member Posts: 37

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,063
    via Email
    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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • glaureglaure Member Posts: 8

    Thanks a lot!

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

    Bye Gunther

  • RourkeRourke Member Posts: 37

    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.

  • SanderSander Member Posts: 10

    @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?

  • Eric_BergeEric_Berge Member Posts: 32

    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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,063
    via Email
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,063
    via Email
    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,409

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • SanderSander Member Posts: 10

    @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.

  • RourkeRourke Member Posts: 37

    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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,409

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • RourkeRourke Member Posts: 37

    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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,409

    You’re very argumentative, are you not, Mr. Rourke?

    WHQL is a process to satisfy driver signing requirements.

    Nope. WHQL is a process to increase overall system compatibility among individual hardware components and their drivers, and to ensure consistency of user experience. WHQL existed before KMCS existed.

    Attestation adding 20 minutes to turning a driver build and you think that's no big deal?

    Yes, I think that’s no big deal. It added 20 minutes to the 6+ month process of bringing out a release of a complex product. I call that immeasurably small, and akin to whether or not I stopped to get coffee on my way back to my office from the lab.

    Every driver signing topic that comes up that you waste time on pushes out every future product you will ever make.

    Dude, you really need to relax more. That’s just plain silly, and you know it. I don’t answer questions on driver signing (or WDF Queues, or Message Signaled Interrupts for that matter) when I would otherwise be developing code. Right now, I’m eating breakfast and watching the sports wrap-up from the previous day (my teams all did well, so I’m happy enough to deal with your rant).

    Driver signing can actually sink the development of a product at legitimate organizations

    Puuuulllllleeeeeezzzz. If driver signing actually sinks the development of a product at a legit org, that org needs to go out of business, because their engineering and their management are too lame to exist. Darwin at work.

    Our company has certainly been approached, dozens of times, by engineering teams that have been stressing out over Driver signing and been actively trying to figure it our for days or weeks. We can usually get them “fixed” in a few minutes, and they’re on their way... no cost to them, and we generate positive karma and some good will. 8 out of 10 of these can be “fixed” just be pointing them to my blog, which they should have been reading in any case ;-)

    Again, the primary issue around singing... 90% of the issues that we encounter with clients and here on the Community... has to do with MSFT’s lack of communication. If somebody at MSFT would just maintain a series of blog posts on “driver signing this month” that explains what needs done, life would be easier for a lot more folks. Fortunately for our clients, tracking what’s up a MSFT is part of what we do, so we can provide that information for them.

    I’m happy to continue the debate, Mr. Rourke, but would you please do me a favor and turn the volume down just a bit? We’re not discussing global warming or nuclear proliferation here, you know? Driver signing isn’t exactly the cataclysmic event threatening the existence of humanity that the tenor of your argument makes it to be.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • RourkeRourke Member Posts: 37

    Nope. WHQL is a process to increase overall system compatibility among individual hardware components and their drivers, and to ensure consistency of user experience. WHQL existed before KMCS existed.

    Of course your statement is 100% true. But my statement is also 100% true: "WHQL is a process to satisfy driver signing requirements". I don't get why this statement is so controversial and objection worthy that you go off on some sort of mission statement. My statement is simply discussing a relevant aspect of WHQL and that should be clear enough to the reader without needing to jump up and down saying you disagree with everything I say.

    If driver signing actually sinks the development of a product at a legit org, that org needs to go out of business
    ...Our company has certainly been approached, dozens of times

    It is puzzling to hear you balk at this notion then go on to say you've already been approached dozens of times to save products stuck on signing issues. And you even acknowledge that all the great information on your forum and blogs (and I really do mean that and thank you for that) aren't always enough. Other consultants have similar stories to tell of companies in trouble with signing and the numbers are sky high. And you say they can be spending days or weeks on it yet then insist time to market never suffers. It's also important to understand someone in your position won't as likely hear from the companies that failed and why. When you toss out a statement into the ether that they just deserve to go out of business it's like just blaming the pilot without stepping back to understand how the design of the aircraft factored into an accident and how it could be improved.

    I can't see anything I have written that is controversial or incorrect. It seems to be you that gets touchy anytime someone is not cheering for decisions made in redmond and I don't understand that. I bring a voice for the lowly end users and the small developers and I think these are both very important groups, especially the end user. The decisions redmond is making are often very painful to these groups and I think it is important to bring awareness to these issues.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE