Driver compatibility with memory integrity and VBS

Memory integrity is a virtualization-based security (VBS) feature available in Windows 10, Windows 11, and Windows Server 2016 and later. Memory integrity and VBS improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS. Memory integrity also restricts kernel memory allocations that could be used to compromise the system, ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable.

Memory integrity is turned on by default on clean installs of Windows 10 in S mode and Windows 11 on compatible hardware as described in memory integrity enablement. On other systems that don't meet the memory integrity auto-enablement requirements, customers can opt in using any of the methods described in how to enable memory integrity.

Application compatibility

Although compatibility with memory integrity has been a requirement for all drivers since the Windows 10 Anniversary Update (1607), some applications and hardware device drivers may still be incompatible. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen). Such issues may occur after memory integrity protection has been turned on or during the enablement process itself. If you're an application developer and want to validate that your drivers and software packages are compatible with memory integrity, follow these steps.

Some examples where we have observed incompatibilities with memory integrity include:

• Anti-cheat solutions with gaming
• 3rd party input methods
• 3rd party banking password protection

We worked hard to mitigate impacted experiences, so if an incompatibility exists for a boot-critical driver, memory integrity protection will be silently turned off if it had been auto-enabled. If you encounter incompatibilities with other apps, we advise that you check for updates for the specific app and version encountering the issue before turning off memory integrity protection.

How to build compatible drivers

Since memory pages and sections can never be writable and executable, the first step is to ensure a clear separation of data and code and not to attempt to directly modify code pages.

• Opt-in to NX by default
• Use NX APIs/flags for memory allocation - NonPagedPoolNx
• Don't use sections that are both writable and executable
• Don't attempt to directly modify executable system memory
• Don't use dynamic code in kernel
• Don't load data files as executable
• Section Alignment must be a multiple of 0x1000 (PAGE_SIZE). E.g. DRIVER_ALIGNMENT=0x1000

Use the latest version of the WDK and Visual Studio to produce compatible drivers when using default settings.

How to verify driver compatibility with memory integrity

There are three steps to verify driver compatibility:

1. Use Driver Verifier (see section below) with the Code Integrity compatibility checks enabled.
2. Test the driver on a system with memory integrity enabled.
3. Run the HyperVisor Code Integrity Readiness Test in the Windows HLK.

Driver Verifier compatibility checks

Driver Verifier has a Code Integrity option flag (0x02000000) to enable extra checks that validate compliance with memory integrity. To enable this from the command line, use the following command:

verifier.exe /flags 0x02000000 /driver <driver.sys>

To choose this option if using the verifier GUI, choose Create custom settings (for code developers), choose Next , and then choose Code integrity checks.

For success, there is no output. The below is an example for a failure output.

Driver Verifier: Enabled for DvCi.sys, flags 0x2000000, build 16299, key o4Dbg8OVJqaBYlqWQ2QvRH

\*\*\*\*\*\*\*\*\*\*\* Verifier Detected a Code Integrity Issue \*\*\*\*\*\*\*\*\*\*\*\*

\*\* The caller 0xFFFFF8094B9852F0 specified an executable page protection 0x40.

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

\*\*\* Verifier assertion failed \*\*\*

(B)reak, (I)gnore, (W)arn only, (R)emove assert? B

Test the driver with memory integrity enabled

Although Windows will turn memory integrity on by default for most systems, there are several reasons that may prevent that from happening. To turn on memory integrity, see How to turn on memory integrity. Then, test the functionality of your driver. Be sure to exercise all code paths in your driver to ensure your driver doesn't perform operations at runtime that are incompatible with memory integrity.

HLK testing (Desktop and Server)

The HLK test HyperVisor Code Integrity Readiness Test must pass for drivers to be approved for Microsoft signing. Memory integrity-compatible drivers are required for both Desktop and Server Editions. The HLK test is a basic test written to make sure that memory integrity-compatible drivers are correctly loaded and run by the OS.

Although simply passing the HLK test is sufficient for a Microsoft signature for the driver, we strongly recommend thorough functional testing with memory integrity enabled. For example, there might be incorrectly-coded memory allocations violating NX protections that cause failures that wouldn't be caught by the test. The driver author should thoroughly test the driver while keeping memory integrity enabled.

During driver development and during HLK testing, memory integrity may need to be disabled, as it can prevent the driver from loading.

The HLK Hypervisor Code Integrity Readiness Test is required as part of the Windows Server Assurance AQ and the flags to enable Code Integrity checks are also set while enabling driver verifier during other HLK tests.

FAQs

What about existing drivers? Do I need to re-build these drivers to get them to work with Windows 10?

It depends. Many drivers will already be compatible. If using standard settings with the old versions of the WDK and Visual Studio, a known issue is that the INIT section is marked as RWX. In Windows 10, however, the W will automatically be stripped, so if this is the only issue then the driver will be compatible.

How do I verify that memory integrity is enabled?

The simplest method is to run the System Information app (msinfo32). Look for the following line: "Virtualization-based security Services Running". It should report: "Hypervisor enforced Code Integrity". There is also a WMI interface for checking using management tools, see Validate enabled VBS and memory integrity features.

Memory integrity can also be checked in the Windows Security app at Settings > Update & Security > Windows Security > Device security > Core isolation details > Memory integrity. For more information, see KB4096339.

Can I verify that memory integrity is enabled programmatically from kernel in order to alter driver behavior?

Yes, you can use NtQuerySystemInformation: https://msdn.microsoft.com/library/windows/desktop/ms724509(v=vs.85).aspx

The SYSTEM_CODEINTEGRITY_INFORMATION structure has a 0x400 value exposed, indicating that memory integrity is on.

How do I fix compatibility issues?

In addition to double checking that there are no W+X pages and the driver sections are aligned correctly as mentioned above, the most likely issue will be improper memory allocation. Information about the Code Analysis warnings related to memory allocation issued is available on MSDN on the following page:

Code Analysis for Drivers Warnings

The following MSDN links show some examples of commonly-used APIs that cause executable memory to be allocated, along with some example fixes:

• C30029
• C30030
• C30031
• C30032
• C30033
• C30034
• C30035

Use the following table to interpret the output to determine what driver code changes are needed to resolve the different types of HVCI incompatibilities.

#include <pshpack1.h>

typedef struct _BAD_STRUCT {
      USHORT Value;
      CONST CHAR *String;
} BAD_STRUCT, * PBAD_STRUCT;

#include <poppack.h>

#define BAD_INITIALIZER0 { 0, "BAD_STRING" },
#define BAD_INITIALIZER1 \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0      \
      BAD_INITIALIZER0

#define BAD_INITIALIZER2 \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1      \
      BAD_INITIALIZER1

#define BAD_INITIALIZER3 \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2      \
      BAD_INITIALIZER2

#define BAD_INITIALIZER4 \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3      \
      BAD_INITIALIZER3

BAD_STRUCT MayHaveStraddleRelocations[4096] = { // as a global variable
      BAD_INITIALIZER4
};

Which APIs are potentially affected?

The following list of APIs that are not reserved for system use may be impacted: