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

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Can we add a new internal root CA to our internal certificate store for driver loading?

henrik_meidahenrik_meida Member Posts: 41
edited April 7 in NTDEV

Lets say that we are a company that wants to use our driver for internal computers only.

Other than going through the Microsoft WHQL for signing it, considering that this is an internal driver and we have full physical access to all the computers, can we someone how tweak with the certificate store of our windows computers ( they are from windows 7 to 10, some bios and some UEFI), and load our drivers this way, by using our own internal certificate to sign drivers? I assume if we somehow let windows know to trust our own internal public key and add our certificate/public-key to the list of root CAs, then if we sign our drivers with the private key it should trust it, right? is there anyway we can make this work? (We cannot use turning test signing on as a solution for this problem)

There has to be a way, it makes absolutely zero sense that even if a company has physical access to every single computer, and they want to use the driver INTERNALLY, they have to send the driver to Microsoft and pass the WHQL test for it to work..

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,427
    via Email
    " (We cannot use turning test signing on as a solution for this problem)"
    - this is going to block your effort.

    Without testsigning on your kernel drivers have to be either cross signed
    by a MSFT trust cert or MSFT signed via WHQL or MSFT signed via
    attestation signing.
    So I suggest you figure out how to whql your drivers for legacy (w7) os
    releases and attestation sign for w10.
    You are in a square peg crisis.

    Mark Roddy
  • henrik_meidahenrik_meida Member Posts: 41
    edited April 7

    @Mark_Roddy said:
    " (We cannot use turning test signing on as a solution for this problem)"

    • this is going to block your effort.

    Without testsigning on your kernel drivers have to be either cross signed
    by a MSFT trust cert or MSFT signed via WHQL or MSFT signed via
    attestation signing.
    So I suggest you figure out how to whql your drivers for legacy (w7) os
    releases and attestation sign for w10.
    You are in a square peg crisis.

    Mark Roddy

    But do you agree that this sounds ridiculous ? So even tho we have physical access to every single computer and we want these Drivers for internal use only, therefore no distribution of it, yet our only option is to pass whql for our drivers, and if some of them can't pass it, then we have to turn on test signing on every single one of our computers, which obviously is not a meaningful solution since that introduces a lot of security issues and our management will never agree to do this..

    Does Microsoft WANT everyone to move to Linux? because it sure feels like it..

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    Does Microsoft WANT everyone to move to Linux?

    It is certainly having that effect on me.

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

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,427

    MSFT sees its future growth in cloud computing. It is just as happy for you to pay for linux compute time as for windows compute time.

    Back to the signing thing: you've given yourself impossible constraints: have to stick with win7, won't even try to whql, won't testsign. So sure give yourself no possible way forward and then get outraged when there is no possible way forward.

    Or you can adapt.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411
    edited April 8

    But do you agree that this sounds ridiculous ?

    Duh! Have you not seen the posts here and on the OSR developer’s blog about over the past six-plus months?

    I’ve explained over and over what’s going on, and how we’ve been advocating with MSFT to get them to change this policy. I’ve come to the sad conclusion that it just is not happening. This is because they THINK they understand the ecosystem, it’s options, and the impact of this decision but they truly do not. And also because there’s no one person that’s senior enough and into whose area of responsibility this problem clearly belongs.

    They really think we’re all stupid and lazy, and we could just pass the WHQL tests if we wanted. ‘Either update the OS you’re using or pass WHQL... if you’re writing a decent driver you should have no trouble passing WHQL’ is basically what they’re thinking.

    The people making these decisions have never written a driver, have never tried to setup the HLKs/HCKs, don’t understand what the WHQL tests actually test, and don’t really know why we’d be using Win7 anyhow. So, when they raise this issue, and OTHER people internally tell them “there’s no reason these people can’t just have their drivers pass WHQL if those drivers are correctly written” they believe it. Real, actual, practical, examples of devices that could never be WHQL’ed are lost on them.

    Nobody has a job where they’re responsible for “not fucking up the entire ecosystem that uses legacy versions of Windows.” And they have no visibility into the size or import of this ecosystem in any case. Flight control systems in the DoD? Systems in the oil and gas industry that run refineries? Tens of thousands of corporate “terminals” for capturing transactions? Im sure they’re thinking “just upgrade that shit, or... you know... pass WHQL.” As if you’re going to be able to even run the HCKs on a system embedded into an aircraft.

    The ordinary feedback mechanisms that can be used to awaken MSFT to a massively bad decision are also not at work here. The OEMs (our primary feedback loop) don’t care, because they’re not shipping new systems with Win7. The big IHVs don’t care because the hardware was sold long ago, and they don’t see the problem. The big ISVs are antivirus, security, and encryption vendors... and they have an “out” (just Attestation Sign the drivers and they’ll load).

    So... in short: it’s a giant Fuck You to the community that uses something other than Windows 10, and would like to update their drivers. The problem is just too small and too esoteric.

    In the meantime, it took me — literally — 2 hours yesterday to get a small and esoteric bug in qemu-kvm hosted on RHEL 8 addressed, a bug fix sent to me, and a promise of an update.

    There’s a message in that.

    (This is slated for editing and will be made into a blog post on the OSR Developer’s Blog)

    Peter Viscarola
    OSR
    @OSRDrivers

  • david_mk85david_mk85 Member Posts: 19
    edited April 8

    @Peter_Viscarola_(OSR) said:
    The big ISVs are antivirus, security, and encryption vendors... and they have an “out” (just Attestation Sign the drivers and they’ll load).

    Doesn't Attestation signing the driver mean that it will load only in Windows 10? because i doubt AntiVirus ISVs would be OK with just supporting windows 10.

    Or do you mean that if big ISVs such as antiviruses do attestation signing, the signed driver will get a WHQL check (the proper EKU in the certificate) regardless, without them having to pass the test?

    I also remember some posts here that they claimed to have been able to load the Attestation signed drivers in Windows 7/8 as well, is this true?

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,427

    For AV at least, they don't have to update drivers all that often, they just update the rules the driver uses. But as far as I know all the major vendors WHQL their stuff. And no, I don't think they get some get out of WHQL free card. It is not an unsurmountable obstacle.

    The process change really is around how to deal with emergency customer problems that might have been dealt with previously by using a release signed driver update. For win7, there is no way now other than WHQL. I guess MSFT is fine with Win7 being dead. For W10 the process is simple: attestation signing. It takes about 20 minutes on a slow day.

  • david_mk85david_mk85 Member Posts: 19

    @Mark_Roddy said:
    For AV at least, they don't have to update drivers all that often, they just update the rules the driver uses. But as far as I know all the major vendors WHQL their stuff. And no, I don't think they get some get out of WHQL free card. It is not an unsurmountable obstacle.

    The process change really is around how to deal with emergency customer problems that might have been dealt with previously by using a release signed driver update. For win7, there is no way now other than WHQL. I guess MSFT is fine with Win7 being dead. For W10 the process is simple: attestation signing. It takes about 20 minutes on a slow day.

    But is it possible to load an attestation signed driver in windows versions other than 10? because i am certain that i have seen some posts here that claimed to load attestation signed drivers in windows 7/8? I mean why shouldn't it work, since attestation drivers have only some additional EKUs in their certificate compared to the cross signed drivers, but they also have the code signing EKU so why wouldn't they load in Windows 7/8?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    Doesn't Attestation signing the driver mean that it will load only in Windows 10?

    Here, once again, we run up against the significant and often overlooked difference between INSTALLING a driver and LOADING a driver. An attestation-signed driver package can only be installed on Windows 10, because they have scent-marked the CAT file to do that. If you are a PnP device, this means you.

    HOWVER, if you have a non-PnP driver that does not need an INF file (and that's a significant fraction of the driver market), then you don't care about the package or the CAT file. And in that case, an attestation signed DRIVER will happily load all the way back to Windows XP.

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    But is it possible to load an attestation signed driver in windows versions other than 10?

    YES. Sort of.

    An attestation-signed driver package can only be installed on Windows 10, because they have scent-marked the CAT file to do that.

    Yes and no.

    For non-PnP drivers, you can right-click install (using an INF) Win 10 Attestation Signed drivers on Win 7 and Win 8.1 -- I have personally tested this. It works flawlessly.

    AV, security, and encryption ISVs are therefore all set.

    For PnP drivers, you can install Win 10 Attestation Signed drivers on Win 7 using an INF, but as part of the process you get scary pop-ups saying the driver isn't signed... but it lets you install it successfully anyway. I have personally tested this multiple times. It works.

    For PnP drivers on Win 8.1, Win 10 Attestation Signed drivers cannot be installed using the INF. So, for Win 8.1 you're screwed. I have personally tested this. It does not work.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • david_mk85david_mk85 Member Posts: 19
    edited April 8

    @Tim_Roberts said:

    Doesn't Attestation signing the driver mean that it will load only in Windows 10?

    Here, once again, we run up against the significant and often overlooked difference between INSTALLING a driver and LOADING a driver. An attestation-signed driver package can only be installed on Windows 10, because they have scent-marked the CAT file to do that. If you are a PnP device, this means you.

    HOWVER, if you have a non-PnP driver that does not need an INF file (and that's a significant fraction of the driver market), then you don't care about the package or the CAT file. And in that case, an attestation signed DRIVER will happily load all the way back to Windows XP.

    @Peter_Viscarola_(OSR) said:

    But is it possible to load an attestation signed driver in windows versions other than 10?

    YES. Sort of.

    So basically Microsoft allows non PnP drivers that are attestation signed to load without any problem if they don't have an INF file? if so, then is this intended? because I think i remember reading an article in MSDN that said attestation signing is intended for Windows 10 only?

    Will this still work after July 1? Can attestation signing be used as a reliable way to load drivers from now on?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    From your excellent blog post:

    “Right. Like people are going to move their shit from Windows to Linux just because we won’t let them update their Win 7 drivers. Right. Sure. You’re nuts.”

    I'm amazed they don't acknowledge this. Two of my clients (both in the defense world) have had me switch their telemetry systems from Windows to Linux precisely because of these short-sighted policies from Redmond. The simple fact is, the operating system Just Doesn't Matter any more. It is totally irrelevant. I'm now quite adept at writing user interfaces and processing systems that work identically on Windows, Mac and Linux.

    I have previously told my personal story. After a lifetime of being a Windows "fan boy", about 7 years ago I bought a MacBook Air 13 for my primary home laptop, just because the package is so sexy. I was AMAZED how quickly I made that transition. After transferring files, I never started my Windows laptop again. (And, by the way, the MacBook Air 13 is by far the best laptop I've ever owned). However, because Apple is now making what I consider to be short-sighted decisions, this month I bought an LG Gram 17 from Costco, wiped Windows, and put Ubuntu 20.04 on it. Again, I am AMAZED at the ease of the transition. Since firing up the LG, I have not turned on my MacBook, and I don't miss it.

    People don't buy computers because they run Windows. People buy computers to solve problems. They'll run whatever solves the problems with the least hassle.

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    So basically Microsoft allows non PnP drivers that are attestation signed to load without any problem if they don't have an INF file? if so, then is this intended?

    I suspect this is just a happy accident, and they didn't think about it. The same blinders that have brought us to this situation are probably telling them that "nobody really writes legacy/service/non-PnP drivers any more".

    Will this still work after July 1?

    Of course, since there is no cross-signing involved. They would have to modify Windows 7 to make it fail, and they aren't going to do that.

    Can attestation signing be used as a reliable way to load drivers from now on?

    For non-PnP drivers, this has always been a good path, and will continue to be a good path.

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    So basically Microsoft allows non PnP drivers that are attestation signed to load without any problem if they don't have an INF file?

    Non-PnP drivers can be installed via INF. You can right-click install them, and they "just work." No warnings. No errors. No pop-ups. Just lovely success.

    On Win 7. And on Win 8.1 -- I've tried this.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411
    edited April 8

    I'm amazed they don't acknowledge this.

    I THINK they just don't see it. And, let's face it, how many times have people said over the years "oh, if you don't do this, people will move to Linux" -- And has it really happened?

    So any time you give them the "people are gonna take the chance to move to Linux" you get the eye-roll.

    The simple fact is, the operating system Just Doesn't Matter any more. It is totally irrelevant.

    Weeeeellll... One of my favorite sayings is: "What you see is a function of where you sit."

    When it comes to DRIVERS the OS certainly matters. And, in most cases, this typically does not resolve in Windows favor. Drivers are harder to write and there are fewer people who know how to write them.

    What, in the past, has caused most of the embedded vendors to choose Windows (in MY experience) is that it was pretty easy to hire a desktop programmer who already knew how to write C# apps -- or such a dev could be easily training to do so -- and then let them loose on writing the GUI for the machine tools, the code that implements the process control logic, or the controls for the cardiology app. There were tons of folks who knew how to write this stuff... so, using Windows made it possible.

    These days, I think this is much less the case, though (in fairness) there is still a large contingent of C# Line Of Business app devs.

    But now, with SOO much stuff "in the cloud" (as Mr. Roberts said) the interface for LoB apps is MUCH more likely to be via your browser.

    Maybe that's how you write your machine control app now... as an app that runs in the browser? I admit: I don't know what the "done thing" is these days.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online