Kernel mode Anti-Cheats in the aftermath of the 2024 CrowdStrike incident

On September 10, 2024, Microsoft hosted the Windows Endpoint Security Ecosystem Summit. It was initiated after the 2024 CrowdStrike incident made it clear that security product vendors require Windows operating system kernel mode access to achieve their goal of protecting devices.

Most Anti-Cheat products apply some of the same strategies that anti-malware products use with kernel mode access. However, I am concerned about rumors and conclusions drawn too early in the gaming community regarding what the results of that Windows Endpoint Security Ecosystem Summit mean for the Anti-Cheat industry. I am not in a position to acknowledge or deny all details, as I simply do not know more than what is already public. However, I can try to paint a picture to give you an idea of what this could really mean for kernel mode Anti-Cheats. Specifically, I am referring to the notebookcheck.net article Microsoft paves the way for Linux gaming success with a plan that would kill kernel-level anti-cheat [1].

A little background

To better understand this article, here’s a short summary of what kernel mode and user mode mean:

• Kernel mode: The product can access (nearly) everything on the computer and has one of the highest levels of privilege possible. If the software is buggy, like in the 2024 CrowdStrike incident, it can crash the computer.

• User mode: The product can only access data that the currently logged-in user can access. If the software is buggy, it will only crash the software itself, not the computer.

Generally, people don’t like kernel mode because you have to trust the product not to do something malicious, like reducing the stability of the system or snooping on data it shouldn’t. Hence, people prefer user mode software because it can’t decrease system stability as much.

Rumors and early conclusions

I will try to debunk some statements floating around in the online community that I believe are not backed by sources and are based on premature conclusions.

Less intrusiveness

From [1]:

Removing kernel-level security software would mean that anti-cheat software would all have to be implemented with user access, making it much less intrusive […]

This doesn’t automatically mean that it makes Anti-Cheats less intrusive. If security products (which Anti-Cheats are, after all) can still access the same information they do now through new Application Programming Interfaces (APIs) in user mode, it only moves the point of failure from kernel mode to user mode. It’s a good thing to enhance system stability and overall trust by removing third-party code from kernel mode, but it doesn’t limit the information that security products need to access.

Please note that the blog article does not mention the word “privacy” once. This initiative is to make the system more stable, not to reduce the capabilities of security products.

Linux compatibility

From [1]:

Many games that use kernel-level anti-cheat software […] are not compatible with Linux, despite that compatibility reportedly being a single toggle in software — however, game developers and publishers are hesitant to enable Linux compatibility, for some reason.

(emphasis mine)

I can attest that it’s not a single toggle in software to make Anti-Cheats compatible with Linux. There are fundamental trust issues when gaming on Linux, because the user could run their own variant of Linux that circumvents all integrity-related features, and the Anti-Cheat wouldn’t know. The stated “some reason” refers to a significant difference in making Anti-Cheat effective.

Killing kernel-level anti-cheat

The headline of [1] states:

plan that would kill kernel-level anti-cheat

Microsoft doesn’t mention in the blog post on the 2024 Windows Endpoint Security Ecosystem Summit that they are killing kernel mode access for security product vendors. Instead, they state that new APIs will be added for vendors to use. It’s a fair assumption that all old methods will still work. It will simply be a matter of market forces pushing security product vendors to switch. If Vendor A can market their product as more stable because it doesn’t run in kernel mode anymore, no one will buy the security product from Vendor B.

Important considerations

Anti-Cheats are not the same as normal security products. Usual anti-malware products protect against attackers that the user doesn’t want on their system. Cheats, however, are deliberately run by the user. That’s why anti-malware products protect against third parties, while Anti-Cheats protect against the user.

Backwards compatibility and other use cases

Most of the functionality that kernel mode security products and Anti-Cheats use are based on general-purpose callbacks provided by the Windows operating system. These general-purpose callbacks are also used by hundreds of thousands of other kernel mode drivers for actual hardware devices and other software solutions. Removing those is a no-go for Microsoft, and for good reason—they serve a purpose.

Microsoft Virus Initiative

Security products have access to more advanced APIs that normal software vendors can’t use. Microsoft initiated the Microsoft Virus Initiative a long time ago to give vetted third-party vendors access to the most deep system callbacks. Only vendors with access to these APIs can replace Windows Defender, for example. Non-anti-malware products don’t have access. Anti-Cheats are not considered anti-malware products according to the requirements outlined by Microsoft.

Anti-malware products can install early launch anti-malware (ELAM) drivers and can protect their processes, which are marked as anti-malware services in a special way. Anti-Cheats will most likely not get access to these APIs and the future changes planned by Microsoft, as they don’t qualify for the requirements to be a Microsoft Virus Initiative partner.