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

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.

1 Like

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.

2 Likes

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

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.

1 Like

I was going to start pushing this upward inside the giant tech company I
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.

1 Like

Testing is definitely going to be harder, no matter the kind of driver.

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