Microsoft: No More Updates Allowed for Drivers on Win 7, Win 8, Win 8.1

Sitting here in 2020 and complaining about policies that don’t make any sense. This one is well down that list.

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

No one is going to put Windows into embedded systems anymore,

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

1 Like

Officially all of our drivers are required to be WHQL signed

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)” said:

No one is going to put Windows into embedded systems anymore,

Hmmm… I don’t know what you mean by this.

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

Actually, I make a good living helping clients put Windows Embedded Compact into their systems.  Also helping to keep their older systems running.  No driving signing needed at all there!

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.

While I wish for Microsoft’s policies to drive users to Linux, I doubt it will happen.  This latest driver signing change is just one more step in their plan to force everyone off Windows 7 and onto lock-in Windows 10.

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
 

> Here at OSR… about half the drivers we write can never possibly pass

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.

Oh well, about that, WHQL is a game. If your driver cannot pass WHQL in its
normal operating mode, then you need a ‘WHQL mode’.

Mark Roddy

then you need a ‘WHQL mode’

Sort of like VW and mileage tests? :wink:

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

@Tim_Roberts said:

Starting July 2021, can we still sign and install a driver signed with a trusted cross-certificate on a Windows 10 machine…?

No. They are shutting down the whole cross-signing ecosystem. The cross certificates will all expire and no more will be created.

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:

@“Wilhelm_Nöker” said:

@Tim_Roberts said:

Starting July 2021, can we still sign and install a driver signed with a trusted cross-certificate on a Windows 10 machine…?

No. They are shutting down the whole cross-signing ecosystem. The cross certificates will all expire and no more will be created.

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.

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: Deprecation of Software Publisher Certificates, Commercial Release and Test Certificates - Windows drivers | Microsoft Learn) 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: Cross-Certificates for Kernel Mode Code Signing - Windows drivers | Microsoft Learn. 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 :wink:

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

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.

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.

x64 Windows 7?

Kind regards, Dejan
https://www.alfasp.com

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.

THAT is interesting. Thanks for that. Something for others (including us) to try.

Peter

Well, attestation-signed driver BINARIES will load just fine, as long as they don’t need an INF. Filter drivers and “legacy” service-based drivers are good. If you need an INF, then you’re screwed, because you can’t INSTALL the driver – the CAT file that attestation signing creates lists only Windows 10. The installation will fail with “this driver was not designed for this version of Windows”.

I’ve split Mr. @DavidXanatos question/issue into a separate topic in NTDEV

and I’ve closed this thread on the base issue, which is MSFT’s impending policy that will prevent drivers on systems other than Win10 from being updated without passing WHQL.

If there are other questions on the base issue, folks can post them wherever and we can discuss whether we should re-open this thread.

Peter

1 Like