SDV Deprecation Announcement

NTDEV
1

Hello Windows driver developer community.
I’m part of the Windows Driver Kit (WDK) team here at Microsoft. I wanted to give an update on our static analysis strategy for drivers.
As most of you know, we’ve supported three different code analysis tools for Windows drivers over the years:

• Code Analysis for Drivers (CaD), AKA PREFast for Drivers.
• Static Driver Verifier.
• CodeQL for Drivers.

Over the years we’ve heard a lot about how useful these have been. Peter Viscarola at OSR wrote a great piece about CA a few years back that we still pass around: It Passes Code Analysis – OSR
Going forward, we intend to focus on CodeQL as the primary static analysis tool for drivers. CodeQL provides a powerful query language that treats code as a database to be queried, making it simple to write queries for specific behaviors, patterns, and more across a codebase. The Introduction to QL and CodeQL for C and C++ pages on GitHub describe the language in more detail, while our Windows-Drivers-Developer-Supplemental-Tools GitHub repo provides instructions on how to get started running CodeQL on your drivers.

The core CodeQL engine is maintained by a dedicated team at GitHub, and it enables developers to write their own queries and provide direct feedback and PRs on existing ones. CodeQL also works on a broader set of driver projects than SDV or CA, and can run outside of an MSBuild context. We feel this is the right way to balance our resources and streamline the process for creating new queries going forward.

We’ve made the decision to retire SDV from ongoing support. As such, it is not available in WDKs newer than build 26017 and will be absent from the Windows 24H2 RTM WDK.

Code Analysis for Drivers is also on our roadmap to retire in the future; however, at present it is still available in the WDK, including in the upcoming 24H2 release.

CodeQL uses an entirely different technology than SDV and CA, and as such it cannot directly ingest existing SDV and CA rules; nor can it integrate with Visual Studio directly at this time. We have ported the CA rules that were previously required to pass the Static Tools Logo test on server to CodeQL, and plan to port more CA rules as well as SDV rules in the future. We also hope to improve Visual Studio integration and the user experience.

Many of you are also familiar with the Static Tools Logo (STL) test, and that in the past SDV and/or CA were required for server certification. Going forward, the only static analysis logs that STL will require are from CodeQL – both for server and client releases. These results still must be provided in the form of a DVL.

We recognize there is still a ways to go before CodeQL can provide the same queries and user experience as SDV. With that in mind, we have a few questions we’d appreciate feedback on:

  1. Given SDV and CA are no longer required for certification, do you intend to continue using these tools?
  2. What SDV rule(s) have proven the most helpful to you over the years? Which, if any, have had issues with false positives?
  3. What CA rule(s) have proven the most helpful to you over the years? Which, if any, have had issues with false positives?
  4. What IDE/dev environment integration(s) are the highest priority? Full Visual Studio? Visual Studio Code? The EWDK?

Please see below for some common questions and answers.

Can I still use SDV and CA?

SDV can still be used by downloading the Windows 11, version 22H2 EWDK (released October 24, 2023) with Visual Studio Buildtools 17.1.5 from Download the Windows Driver Kit (WDK) - Windows drivers | Microsoft Learn. We recommend only using Enterprise WDK to run SDV at this time. Using older versions of the standard WDK in conjunction with recent releases of VS is not recommended, as this will likely result in analysis failures.

SDV is not available in Windows 24H2 WDK or EWDK releases.

CA is available in the Windows 24H2 WDK and EWDK, but is planned to be retired at a future date.

I’m still certifying for downlevel OSes, like WS2019. What do I do?

You have a couple of options:

• WS2022 (and/or earlier OS versions, WS19, WS16) must be submitted using SDV/CA logs.
• WS2025 (and earlier OS versions, WS22, WS19, WS16). Must submit CodeQL results for WS2025, and waiver granted for SDV/CA log requirements for down level OS.

I heavily rely on a rule that’s present in SDV or CA but not in CodeQL. What do I do?

Let us know! The more we hear that a given class of rules is helpful and necessary, the easier it is for us to prioritize developing CodeQL versions of them.

Additionally, as an open-source query language, you can try writing CodeQL queries for your specific needs. We accept pull requests into our CodeQL repo: microsoft/Windows-Driver-Developer-Supplemental-Tools: Supplemental open-source components for use in developing device drivers for Windows. (github.com)

Why does CodeQL require a separate download from VS and the WDK?

Licensing agreements with GitHub mandate that CodeQL is shipped separately.

Do I need a GitHub Enterprise plan to use CodeQL?

No. CodeQL licensing allows the use of CodeQL for driver certification without any paid GitHub plan.

I rely on suppressions to run CA rules without noise. Can I still use my existing suppressions when testing with CodeQL?

Yes. We’ve developed a CodeQL library to translate CA suppressions into CodeQL-style suppressions, and an associated query that will honor suppressions when run alongside other queries.

2

This is good news as running SDV has become very problematic.

Full integration of codeql into the msbuild build tool chain would be ideal. That way it would be available as a standard build step. People using VS or VSC or simply command line ewdk builds would all get the same results.

Meanwhile the licensing for codeql is a problem. If I take its restrictions literally I would be in violation for simply trying it out, as that would not be within the permitted use cases.

3

Hmmmm.

This proves that if you ignore a decent set of tools long enough, and allow them to atrophy to the point where they’re barely usable, then almost nobody will care when they’re gone. Let them rest in peace. We’ll remember them fondly, from the days when they were useful.

Both SDV and CA have gotten so bad, and so unpredictable, over the past several years that I suppose it’s a net positive that they’re gone. At least we won’t rely on them anymore, just to be frustrated when they miss some serious latent error that they had previously caught.

Deprecating SDV? Meh. :face_with_diagonal_mouth: As Mr @Mark_Roddy noted, it’s been a PITA to get working for ages, and it’s found less and less useful stuff, at least for me. So… whatever.

Moving away from CA, OTOH, will be seriously problematic… but I guess we need to wait to see what this really means when it happens. Moving away from the driver specific rules in CA? Yeah, well, a lot of those don’t really work the way they should anyway, and haven’t for years.

In all this, I do wonder what will happen with the enforcement of all the SAL annotations. Particularly, the advanced ones. My favorites include locking annotations (such as “guarded by”)… does those get enforced? And the complex IRQL annotations? Is this just another way of telling us SAL is soon to be dead, a “failed experiment” as a compiler expert I once talked with said to me a few years back?

Having CodeQL run separately from the build steam seems to be a terrifically bad idea. That just means it’ll get run rarely. The WDK team absolutely needs to provide an integrated way to get CodeQL to run as part of the build stream, and not leave this to each member of the community to figure out on their own.

I’m deeply enmeshed in a big project right now, but when I have the time, I’ll dig deeper into this. In the meantime, I’d love to hear more from the WDK team around what rules we still get, and what SAL annotations be utilized.

4

For my team, I will continue to insist on the use of SAL whether the tools consider it properly (or at all) or not. For the human writing the code, and the other humans reading it, these annotations are invaluable for communicating intent and detecting errors.

Their presence also makes the problem of creating effective code analysis for C or C++ code much easier. Presumably leading to better tools. Which presumably leads to better software overall

5

@Paul_Eze ... that was an actual question, in case that wasn't obvious:

6

@Peter_Viscarola_OSR CodeQL has support for interpreting SAL annotations, and we’ve made use of that functionality in our IRQL queries and library. We do not yet have support for the locking annotations or queries designed to use them. While we can’t guarantee any specific additional annotation work at this time, feedback on what annotations/what CA rules are most helpful makes it easier for us to prioritize adding additional support

7

It would be a big disappointment if SAL is abandoned.

My team works on a code base that has a lot of history. We started with NT 3.51 and SQL 6.5 in the 1990's and before SAL, the same information was included in the source via comments. Parameter usage, correlation between parameter values (usually buffer + length, or size & count) as well as locking and success / failure criteria. But comments are inherently unstructured and as changes happen to the code can become different from the actual parameters and their present usage. SAL enforces a structure and will actively warn if the usage has changed without updating the annotation.

These days, I do much more code review than actual coding, and some extra benefits to SAL have become apparent to me. The most obvious one being that when the usage of a function / parameter / struct member cannot be easily matched with a SAL annotation, the code is probably wrong. Reviewing sal.h is also a good way for junior programmers to learn.

One feature that would make SAL much more useful would be to consider rundown protection / reference tracking. Basic SAL is very good for tracking buffer overrun issues. locking SAL works okay except for interlocked and opaque locks (different header files for internal vs external - a C version of C++ private declarations). But it is terrible for code that uses reference tracking.

In my opinion, SAL is a very important tool that should be maintained and improved.