Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.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/
Microsoft: No More Updates Allowed for Drivers on Win 7, Win 8, Win 8.1
Peter_Viscarola_(OSR)
Administrator Posts: 9,131
This is bad news... and it's serious.
In short: As of July 2021, Microsoft will no longer allow new releases of drivers to be cross-signed and loaded on Windows 7, Windows 8.1, or Windows Server 2012 R2 (including Windows Embedded 8 and Windows Embedded 8.1). You can read the policy here.
Folks have raised this issue several times here in this forum in the past. One of the most recent was Mr. Roddy in this thread. I have always urged posters not to worry, because I assumed that this policy would be "corrected" -- Apparently, I have been overly optimistic.
For more than a year, folks here at OSR have been been engaged with Microsoft over this issue. Our understanding (or, perhaps, it was simply our hope) was that this policy was going to be "fixed." Surely, we reasoned, Microsoft is not going to prevent us from releasing updated drivers for versions of Windows that are still supported by Microsoft. We heard rumors that Attestation Signing would be extended to cover versions of Windows prior to Windows 10.
Apparently we were mistaken. Despite all our efforts, we have been unable to identify ANY plan that'll allow folks to release updated drivers for versions of Windows prior to Windows 10.
So, as of July 2021, if you want to update a driver that runs on a Windows version other than Windows 10... forget it. You're screwed. And, worst of all, your customers are screwed.
According to Microsoft's published plans, the only way to update a driver for a version of Windows other than Windows 10 is to have that driver pass the HLK/WHQL tests. That is, assuming that your driver falls into a category where there are HLK tests. And your driver can pass those tests. There are many, many, drivers -- especially drivers for special-purpose systems -- that will never be able to pass the HLKs and have no reason or need to pass the HLKs.
I've written more about this here.
If we work together, we can get Microsoft to change this plan. This community has done it before.
Work your technical contacts. Get the message clearly presented to the folks you work with at MSFT.
Even more important, you must explain the problem to the managers at your company who regularly engage with MSFT. You must get your execs and your managers to raise this issue with their MSFT contacts.
Because if we don't change this policy, lots of Windows users are going to be put in very difficult positions.
The time to act is now, folks. Microsoft needs to hear from you and from your management team.
The clock is ticking...
Peter Viscarola
OSR
@OSRDrivers
Howdy, Stranger!
| 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! | ||
| Kernel Debugging | 13-17 May 2024 | Live, Online |
| Developing Minifilters | 1-5 Apr 2024 | Live, Online |
| Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
| Writing WDF Drivers | 26 Feb - 1 Mar 2024 | Live, Online |
Comments
They've recently added a table to the policy page.
I hope "Windows Server 2008 and later" means "Windows Server 2008 and Windows Server 2012" and "Windows 10" means "Windows 10-based OSes including Windows Server 2016 and Windows Server 2019."
It does... but how does that help?
After 1 July 2021, you pass WHQL or you can't install your drivers on any OS other than Windows 10. Full stop.
Even though some of these versions of Windows will be supported well into 2023.
Peter
Peter Viscarola
OSR
@OSRDrivers
It helps if you only care about future development for Windows 10-based OSes. For new drivers that will only support Windows, but would like to also support Windows Server, I would have appreciated clarity here that newer Windows Server versions will continue to support Attested Signing. You'd think that they would have been careful to get this right after the years of waffling on and poor communication about the the threatened WHQL requirement for Server OSes.
I wholeheartedly agree that for maintenance purposes or for continuing driver development on Win7/8.1 this is a complete disaster.
Yes, agreed, on all points. And I agree that the article isn't written with anything remotely resembling sterling clarity.
In fact, I've been trying to explain that page via email over the past two hours to a well known journalist who covers issues related to Microsoft.
Peter
Peter Viscarola
OSR
@OSRDrivers
In the present environment it seems unlikely that an issue like this one will get much traction. Think about it from the opposite point of view. We're going to shutdown the ability to develop new drivers, or deploy corrected drivers in the last 1-2 years of a 10 year support period and the community wants to have the ability to make a new build on the second to last day; and then we then have to field a support call on on the very last day. All in a way of viewing OS versions that we now consider obsolete while we push all of our 'progressive' clients towards Microsoft 365.
Whatever I think about the policy, that seems a tough road to get this done
In order to solve a problem one must first define what the problem is. Someone needs to ask Microsoft the key question: "What problem are you trying to solve?" Maybe there is a better, more elegant solution for Microsoft and us.
What irks me most is that this is totally unnecessary. What is the net recurring cost to Microsoft of maintaining this capability? Zero. It just seems mean-spirited. I've come to expect this from Apple, but not from Microsoft.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
I recently discovered that drivers signed with a trusted cross-certificate (even if they are signed now) can still be installed in Windows 10 if secure boot is disabled in BIOS. Does the new policy also affects this? Starting July 2021, can we still sign and install a driver signed with a trusted cross-certificate on a Windows 10 machine that is not running in testsigning mode but has secure boot disabled? This is the only workaround I found on how independent-developers can sign and launch a windows 10 driver.
I literally do not understand, and I have not been able to get anyone at Microsoft to give me an explanation, of what they’re hoping to accomplish with this policy.
It feels to me like some middle manager not understanding the vastness of the ecosystem. If the goal is to push people to upgrade to Win10, this is a very wrong headed idea.
You can’t just run Windows Update on a carefully configured system running Windows Embedded in a medical device, or on an aircraft, or on a system that does continuous process control in a refinery. These systems have all been specifically qualified with specific versions of Windows and updating to a different version of Windows accomplishes exactly NOTHING except destabilizing these systems.
You can’t just upgrade 85,000 corporate desktops running dozens of LOB applications.
This is why we were convinced this policy would be changed. But, without the community pushing back, it looks like it IS going to happen.
Note that the computer system OEMs don’t care about this policy, because all the drivers on their systems have to pass WHQL out of the box. So, it’s up to the IHVs and ISVs.
Peter
Peter Viscarola
OSR
@OSRDrivers
No. They are shutting down the whole cross-signing ecosystem. The cross certificates will all expire and no more will be created.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
work for, but I stepped back from that: they aren't going to have a problem
with the policy. Officially all of our drivers are required to be WHQL
signed,so there is nothing to officially complain about. The impact will be
on test and support, and that impact is invisible above a certain level.
I was going to point out that this kills the use of windows embedded as an
RTOS in the DIY/hobbyist world, but that ship sailed a long time ago.
Sitting here in 2020 and complaining about policies that don't make any sense. This one is well down that list.
+1. No one is going to put Windows into embedded systems anymore, so yep... it looks like farewell salute of MS to embedded makers.
Hmmm... I don’t know what you mean by this.
If you’re saying that this policy might cause folks to rethink their use of Windows Embedded... maybe. In many cases, moving to a new version of Windows in an embedded system is a Big Deal. If they view this policy as a violation of trust, then they might say “If we have to consider another version of the OS, we might as well consider a different OS and avoid getting screwed over like this in the future.”
I see that, for sure.
Peter
Peter Viscarola
OSR
@OSRDrivers
You’re lucky that you write the types of drivers than can be WHQL signed.
Here at OSR... about half the drivers we write can never possibly pass WHQL.
Peter
Peter Viscarola
OSR
@OSRDrivers
Yes, violation of trust - but even much earlier Windows embedded become too encumbered and hard to deal with, when other options have developed.
At least, where I live, popularity of Windows embeddedhas dropped to zero.
I haven't heard anything related to Windows embedded, IoT and WinCE from my network since years ago.
-- pa
Greg
On Sat, 17 Oct 2020 22:38:12 +0000 (UTC), Pavel_A wrote:
OSR https://community.osr.com/
Pavel_A commented on Microsoft: No More Updates Allowed for Drivers on Win 7, Win 8, Win 8.1
> @Mark_Roddy said:
>
> I was going to point out that this kills the use of windows embedded as an
>
> RTOS in the DIY/hobbyist world, but that ship sailed a long time ago.
+1. No one is going to put Windows into embedded systems anymore, so yep... it looks like farewell salute of MS to embedded makers.
First, Windows is too entrenched in the Enterprise desktop. It gives the "Gatekeeper" IT groups too much power to control and lock the desktops. Even though viable alternatives exist for almost every general desktop application, IT groups, CIOs, etc won't take the risk to jump ship.
Secondly, Linux is a second-class OS to most game manufacturers. Let's be honest, gaming drives almost the entire non-enterprise desktop.
Supercomputers are already exclusively the domain of Linux and derivatives now. Corporate servers are a mixed bag.
I make a living doing embedded on both. I've been doing Windows Embedded for over 20 years now. It WEC7/WEC2013 consulting still drive a large portion of my income. Increasingly Linux is becoming my majority income producer. As long as WEC pays enough to make it worthwhile, I'll continue. The day it doesn't, all of my Windows systems will be entirely Linux.
Windows 10 update policy has had me cussing on more than one occasion. It's infuriating to find a 3-day test was interrupted in the middle of the night for an unannounced "update" that Microsoft has decided was more important. Or when it take 5 hours to reboot because of a major "upgrade" that could not be postponed. How I wish I could have billed Microsoft for the $700 in lost billing time.
OK, done ranting,
Greg
> WHQL.
A lot of FS filters do not really pass WHQL also, due to their design.
(I had a few myself, where we simply had to deny open by file ID for
example, and thus cannot pass HCK tests - and this is the simplest
such case).
With the cloud taking hold over a lot of enterprises, it is a matter
of thime for them to figure that 90% of the users, at least, can
switch to Linux.
I am sure MS is aware of this, and already not counting on Windows as
the main driver of their income.
normal operating mode, then you need a 'WHQL mode'.
Mark Roddy
Sort of like VW and mileage tests? ;-)
But seriously, that can go a long way in many cases. We call it “conformance mode” — but getting certain kinds of drivers/devices to pass can still be very, very difficult.
Peter
Peter Viscarola
OSR
@OSRDrivers
Exactly. And because that's how the policy change works (i.e. they don't have to roll out any specific Windows updates, they will just sit and let things happen), July 2021 is not even the date to worry about. Depending on your certificate provider, your ability to create valid cross-signed drivers will end much sooner: in April or February 2021.
Hello,
I have some detailed question about the following quote:
I understand, that if they do not allow ACs to sell any more cross certificates, the existing cross certificates will start disapeare and thus at one point in time no more cross signign will be possible. Effectivly cross signign dies out.
But assume, you still have a code signing Certificate from any AC with cross signign capablity and both, the certificate itself and the cross certificate are valid beyond 30. June 2021.
Is it then possible and ok (with MS compliance) to sign your driver with that certificate? Will that work?
I would propse a yes: Cause I cannot image how Microsoft will pe able to force the policy on the clients with the deadline 30. June 2021? That would either require a Windows Update on clients, which in fact is not possible any more on Win 7, right? Or the have some easter egg programmed into Win 7, which revokes drivers with certificates that are valid longer than 30. June 2021? Later sounds a bit strange to me.
And to dig even more into the nasty documentaiton of Microsoft Policies.
On this page: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/deprecation-of-software-publisher-certificates-and-commercial-release-certificates) Mircosoft does not mention any specific date in the whole text except for that strange Table on the bottom of the page.
Moreover they state at the beginning of the page:
Existing cross-signed root certificates with kernel mode code signing capabilities will continue working until expiration
A little bit more down the page they say: The majority of cross-signed root certificates will expire in 2021
But on the same page, the have a hyperlink to this page: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing. And there you'll find a list containing cross certificates which a valid till 2023 or even 2025 (e.g. Entrust Root Certification Authority – G2 d8 fc 24 87 48 58 5e 17 3e fb fb 30 75 c4 b4 d6 0f 9d 8d 08).
So taking all this together, what's the real meaning and final impact of this table on the first page?:
I'm again asking the question from the beginning of my post:
How do the come to say there is a deadline on 30. June 2021? How would the enforce this policy?
Hoping anybody here can give me a satisfying answer
Greetings Matthias
That's an interesting observation. I'd have assumed (after doing the basic sanity check of verifying the expiration date on the GlobalSign cross-certificate that I use every day) that the table captioned "What is the expiration schedule of the trusted cross-certificates?" correctly summarizes the expiration dates of all published cross-certificates. But like you said, in some details it is in contradiction to the table from the download page "Cross-Certificates for Kernel Mode Code Signing".
And just like I still assume that for me as a GlobalSign customer, April 15 2021 is the exact deadline to worry about, now I suspect that users of a GoDaddy certificate or one other from the "New Cross-Certificate List" might turn out to be the lucky late arrivals with about two more years of authenticode-signed kernel-mode drivers still remaining.
It's complicated, and the community isn't getting a huge amount of info directly from Microsoft.
As far as I know, the CAs have been asked by MSFT to not renew any of these certs... and the cross-signing certs were all expiring by 1 July 2021.
The REAL root of this issue is that the MSFT cert (that the cross-certs chain-up to) that's hard-coded in the OS will be expiring "sometime in the future." That's the "hard" expiration date. I don't know, but I suspect this hard expiration is a year or two off.
So, as usual with these things: It is what it is. This is an ever-changing situation.
We've been trying to work with MSFT to get this policy changed, or to (for example) get Attestation Signing extended to the down-level operating system versions. There's considerable pushback on this... with the MSFT position being: "People should just pass WHQL and they'll be fine."
I've been trying to make the point that there are drivers that -- by their nature, environment, and design -- will NEVER pass WHQL. Folks in the WHQL organization find this difficult to believe.
What we really need are members of the community to contact MSFT and make their concerns known. If you have a driver that CANNOT pass WHQL (not because it's badly written, but because it inherently can't do it due to the nature of the device) it would be VERY helpful if you contacted MSFT support and said "My driver can't pass WHQL" -- this would at least give us ammunition to demonstrate that there are legit cases where there MUST be an alternative, other than "pass WHQL."
Peter
Peter Viscarola
OSR
@OSRDrivers
Matthias, there's (at least) three parts to cross-signing. You get a certificate from a CA, saying that they trust you. Microsoft issues a cross certificate to the CA, saying that they are trusted by Microsoft. Then there's a certificate from the Microsoft Code-Signing Root at the top level. That's the ONLY certificate that the kernel recognizes. The rest of the chain cedes authority to the code-signing root, and the kernel checks that.
So, if Microsoft lets the code-signing root expire, the whole chain comes crashing down. You can't sign any more.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
We've tested submitting a driver for attestation signing, rather than WHQL signing, without the driver file having an embedded EV signature. Such attestation signed drivers, despite the documentation (and the statement from Microsoft quoted by Peter previously in this thread) implying otherwise, load successfully on Windows 7 SP1 systems that have had the SHA-256 support update installed.
Kind regards, Dejan
https://www.alfasp.com
THAT is interesting. Thanks for that. Something for others (including us) to try.
Peter
Peter Viscarola
OSR
@OSRDrivers