Microsoft Ignite: Windows driver development news

NTDEV
1

Just in case you missed the future of Windows driver development:

Preventing incidents through driver resiliency

...

In short, we’re raising the bar for driver signing and making it easier to build reliable drivers for Windows.

What’s changing:

  • Driver signing will require a higher security and resiliency bar with many new certification tests.

  • We are expanding Microsoft-provided Windows in-box drivers and APIs so partners can replace many custom kernel drivers with standardized Windows drivers or move logic to user mode.

  • Over the coming years, we expect a significant reduction in code that runs in kernel mode across driver classes such as networking, cameras, USB, printers, batteries, storage and audio.

We will continue to support third-party kernel mode drivers. We will not limit partners from innovating where we don’t have Windows in-box drivers, or from using kernel mode drivers where required to help ensure a great Windows experience and for scenarios without in-box coverage. Graphics drivers, for example, will continue to run in kernel mode for performance reasons.

For kernel-mode drivers, we’re adding practical guardrails that improve quality and contain faults before they become outages. These include new mandatory compiler safeguards to constrain driver behavior, driver isolation to limit blast radius, and DMA-remapping to prevent accidental driver access to kernel memory.

...

That almost sounds like a charm offensive for us. However, I have a feeling that this doesn't mean we'll have less work to do, but who knows, let's stay positive.

2 Likes
2

We will continue to support third-party kernel mode drivers.

Considering the experience of those locked out of the hardware dashboard the word ‘continue’ is a bit of a slap in the face.

3

Driver signing will require a higher security and resiliency bar with many new certification tests.

I’d like to see some greatly expanded explanation of this.

  • How is the driver signing process changing?
  • What are the new certification tests?
    • Do we have a new HLK version that is required to be used to execute these certification tests?

These include new mandatory compiler safeguards to constrain driver behavior, driver isolation to limit blast radius

  • What are the new compiler settings which will be required?
  • What is the minimum version of Visual C++ that is needed to use them?
  • What are the constraints on driver behavior that are being implemented
  • What is “driver isolation”, how is it enforced and what impact does it have on device driver design & implementation?
1 Like
4

Driver signing will require a higher security and resiliency bar with many new certification tests.

I really hope this does not mean the end of attestation signing.

2 Likes
5
6

| The learn.microsoft.com page says:

Non-isolated driver Isolated driver
INF copies files to %windir%\System32 or %windir%\System32\drivers Driver files are run from the driver store

That may be nice for drivers that connect to specific Windows kernel APIs, like NIC drivers, graphic drivers, disk drivers.

However, I’m maintaining (for more than 20 years now) a “driver package” for specific PCI cards and USB devices that can provide Windows systems (beside other OSs) with very accurate time.

The package provides a kernel driver that uses a proprietary interface to talk to the devices, a couple of DLLs that talk to the kernel driver and provide some user space API functions, and some user space programs that use the API functions from the DLL to talk to the devices: get the time from it, monitor the status, setup some configurable option on the device, etc.

If you install the complete package, you can be sure that the communication between the user space DLLs and the kernel driver is always consistent and doesn’t cause any Windows problem. As said earlier, this has been working very well, without any problem, for more than 20 years now. Effectively, since Windows NT.

If instead the kernel driver is installed via the driver store and the remaining components are installed via a normal software package, care must be taken to ensure that the kernel driver and the other components are a perfect match. Otherwise, this may not work properly.

I bet this is the same for every special hardware that doesn’t fit into the NIC / graphic / disk etc. driver categories.

So IMO it’s a very bad idea to generally restrict driver installation to the driver store only because the result is the opposite than expected.

7

Can you elaborate on what is the opposite of expected?

I would think running from the driver store actually improves your versioning concern. If files are in system32, you can’t guarantee (without additional checking) that you have the correct version of the file there, any version of your software may have been the most recent to copy to the directory. If it’s running from the driver store you have a fixed, (effectively) versioned path to the binary.

8

For example, we have GPS/GNSS PCI cards where you can read the current receiver position or configure the antenna cable length to get the best possible time accuracy on the card, or select which GNSS systems (GPS, Glonass, Galileo, etc.) to use. There are IRIG time code receivers that need to be configured for the time code format to be decoded. New IOCTL codes and associated data structures are introduced whenever the need arises.

The DLLs communicate with the driver via IOCTLs by passing different data structures down to or up from the device, and the kernel driver writes the structures to or reads them from the PCI card.

In this context, “expected” would be that the IOCTL codes and associated data structures used by the DLLs perfectly match those supported by the kernel driver, and those e.g. supported by the GUI monitoring and configuration program, so that everything just work flawlessly. This is always the case if you install the DLLs and kernel driver from the same setup program.

If (only) the kernel driver was distributed by the driver store, I wonder how the driver store knew which was the most appropriate version of the kernel driver, and users had to figure out which was the most appropriate version of the user space part of the programs to match the kernel driver.

Also, if the driver store rolled out a new version just because it became available, the user would have to be notified and forced to find out the appropriate version and install these, too. In my opinion, this is very much error prone, and after a partial upgrade the programs might stop working flawlessly together, which is what I meant by “the opposite of expected”.

We also have a bunch of customers who have certified their application with a particular version of our driver package, and they won’t upgrade the driver package without a very good reason because they had to re-certify their system every time this happens.

There are also customers that explicitly install a developer version of the driver package to test a new feature that is introduced by a new version of a PCI card, or a new firmware version of the card. This doesn’t affect the Windows system at all, but the customer’s application which may test and try the new feature before it is officially released.

I wonder how all these customers would react if the Driver Store installed a new or another version of the kernel driver unsolicited, simply because this other version exists.

So once again, it may be a good idea to install standard drivers via the driver store, but doing this generally and exclusively for all drivers is a really bad idea, IMO.

9

Maybe I’m missing something, I don’t see how any of this changes because the location of the kernel binary is different. The contents of the driver store are still controlled by your setup program, any new versions would come from your setup program. Assuming you are using a PnP driver to install your binary/service, the current flow is:

Setup program → DiInstallDriver/SetupCopyOEMInf/whatever → Package copied to driver store → Binaries copied to system32\drivers → Driver service points at system32\drivers binary path

With isolation requirements, the flow is:

Setup program → DiInstallDriver/whatever → Package copied to driver store → Driver service points at binary path in driver store

Maybe you’re not installing using a PnP driver and you’re just copying the binaries to system32\drivers and creating the service - in which case there’s no reason you can’t continue doing that (although I don’t recommend it in most cases).

Either way, the driver store logic is unchanged from the existing flow and the only change is that we don’t want you copying driver files into system32(\drivers). If the driver store was going to change a binary, it would already be doing it to your existing solution.

2 Likes
10

How do you think that is going to happen on its own? The Driver Store only gets updated when you intentionally install a new driver, or an operating system upgrade finds a newer version (where “newer version” is well-defined) in Microsoft’s central driver library. It would only be in the driver library if YOU had put a WHQLed and signed driver in there.

I think you are worried about magic actions that simple do not occur in real life. It occurs to me that you may be confusing “Driver Store” with “App Store”. The Driver Store is a directory on your computer (\Windows\System32\DriverStore). It’s not the central master warehouse of tested drivers in Microsoft’s cloud. That’s called the “driver library”.

1 Like
11

Zac, Tim,
looks like I’ve been confusing “Driver Store” with “Microsoft’s central driver library”. :frowning:

I was assuming that new drivers had to be uploaded to Microsoft and then would be automatically distributed via Windows Update, which would have caused the problems I mentioned.

Actually I’m doing attestation signing, and the installer basically uses the SetupCopyOEMInf method to install it.

Thanks @Zac_Lockard and @Tim_Roberts for your replies and clarification.

1 Like
12

Keep in mind that there is also the Core Isolation feature where kernel drivers run in a virtual environment within the kernel.

And there is Printer driver isolation as well.

I feel a bit isolated now :laughing: .

13

We also read this as referring to Core Isolation or something similar.

I’m frustrated that this blog post dropped so many bombs (new driver tests will be required, some vague new isolation feature, new “guardrails” and compiler requirements) that may require significant rework, but with no indication of when this is going to hit, what it all really means, or when or where we can expect further information.

14

Yeah… none of this looks even REMOTELY like a charm offensive, OR good news to me.

First of all, it continues to propagate the confusion of the certification tests with quality tests. While some certification tests are quality tests, for better or worse the vast majority of certification tests are focused on whether drivers behave according to Windows policy.

The part about partners replacing custom kernel-mode drivers with in-box drivers doesn’t bode well for innovation. You know “we GIVE you a StorPort NVMe driver… you don’t NEED to write your own” – Really? Well, once you folks make a StorPort NVMe driver that’ll make my hardware run at the speed of my custom driver, I’ll think about it.

The part that signals a shift to user-mode could be either good or bad. But, unless accompanied by serious architectural changes, I’m betting it’s not going to be good. The inclusion of “storage” on that list terrifies me.

Here’s a nice line: “We will not limit partners from innovating where we don’t have Windows in-box drivers” – Translated this means: In the future, IF we provide an in-box driver that’ll make your device work, albeit less than optimally, THEN we will prohibit you from loading your custom driver.

“driver isolation to limit blast radius” – Blast radius. Awesome turn of a phrase.

15

I'm enjoying retirement. I was a pilot fish feeding off the great white shark MSFT just long enough, and not too long.
Ai Ai Skipper!

16

image
image347×145 67.6 KB

17

@Peter_Viscarola_OSR Well, I thought you would get the sarcasm in plain sight.

But honestly, a lot might just be marketing speech to show that MSFT is really working on the “Security first“ approach and the actual changes for most of us might be more formal, like that new account verification we had to do.

However, It might be very different for the Anti-virus scanner industry as MSFT can’t risk another CrowdStrike disaster.

18

I’ve missed clever sarcasm before. Perhaps an occupational hazard.

Here’s my concern: MSFT, not without some justification, has long viewed 3rd party drivers as a sort of necessary evil. One that exponentially decreases OS reliability and security. And, therefore, has been searching for a way to “lock down” the platform better.

The Crowdstrike disaster could provide the attention and visibility that was needed internally to drive (and, more importantly, to fund) a full-on offensive against third party drivers.

Now, I’m not saying the some of this isn’t justified, or even that it would necessarily be a completely bad thing. There are indeed waaay too many bad drivers, and too many ways to exploit the I/O subsystem architecture for the evil intents.

Unfortunately, this causes 2 really big problems:

  1. As usual, Microsoft continues to conflate “Windows” with PCs, laptops, and servers. And they entirely miss the fact that there’s a large embedded device market out there that uses Windows. From industrial control systems, to instruments, to medical equipment, to retail systems… they’ve really managed to put “Windows everywhere.”
  2. As usual, Microsoft misses the fact the OEMS, IHVs, and ISVs need to innovate… and a lot of that innovation often requires the intervention of exceedingly clever (yet entirely architecturally appropriate) kernel mode drivers.

We’ve seen the above two factors playing out over and over again in Windows history. And I fear we’re about to get to see it again, soon, “right between the eyes.”

I understand why they miss the embedded market so often. Internally at MSFT when you talk about Windows license numbers, you talk in quantities of millions. There are few, if any, embedded or industrial control systems that sell in these quantities and thus in the eyes of Windows management they could for zero (millions of) licenses… so it’s hard for them to care or make an exception.

I also understand why they miss the need for the industry to innovate. Microsoft is a huge company, and it’s easy for them to think they’ve “got things covered.” They just do not see the issues and limitations… the chances to innovate and improve… that a smaller IHV can (quite profitably) see. So we get narrow, antiquated, opaque, and arcane models like StorPort that are supposed to “make our lives easy” and they don’t understand why anyone rational would “need more than this.” It’s equal parts limited vision and hubris.

So, yeah… I’m concerned that these particular fields of third-party driver development are going to get swept up in a wave of “good intentions” while making the system “more reliable.”

Folks who work for companies that rely on these areas remaining relatively unchanged, need to get their vice presidents to understand how changes at MSFT could affect them, and mobilize to advocate directly with MSFT. And, no, no amount of “feedback” at the TAM level is sufficient. OEM and IHV and ISV VPs need to talk to MSFT directors and VPs and tell them what they need. And if we don’t do that, I fear we’re gonna get screwed.

2 Likes
19

It is almost as if the WDF team tried to improve the situation 20 (!) years ago.

20

AH…. those were the days.

Shit, Doron, that was 20 years ago now, wasn’t it. Does that mean I have to stop referring to it as “the new driver model”???

Can you please go back there, smack some folks on the side of the head, and get them to re-vector their Windows Drivers in Rust project, please, so that it’s not just a translation layer for calling existing WDF functions in Rust? Sort of like you guys did for KMDF and WDM back in the day?

Please??

1 Like