Kernel patch protection: frequently asked questions
Kernel patch protection in the x64-based versions of Microsoft Windows Server 2003 with Service Pack 1 (SP1), Microsoft Windows XP, and later versions of Microsoft Windows for x64-based systems protects code and critical structures in the Windows kernel from modification by unknown code or data. This topic answers frequently asked questions about kernel patch protection in Windows.
Windows 7 and Windows Server 2008 R2 include updated support for ACPI processor power management (PPM) features, including support for processor performance states and processor idle sleep states on multiprocessor systems. This topic provides details of the support in Windows 7 and Windows Server 2008 R2, describes how PPM functions with the Windows 7 and Windows Server 2008 R2 power policy store, and provides guidelines for firmware developers and system designers.
This information applies to the following operating system:
- Windows XP Professional x64 Edition
Q: What is kernel patching?
Kernel patching is the practice of using internal system calls and other unsupported mechanisms to modify or replace code or critical structures in the kernel of the Microsoft Windows operating system with unknown code or data. "Unknown code or data" is any code or data that is not provided by Microsoft as part of the Windows kernel.
Developers sometimes patch the kernel by changing a function pointer in the system service table, which is an array of function pointers to in-memory system services. (Code that does this is sometimes said to hook the system service table.) When a call is made to invoke a system service, the service dispatcher uses the service number to retrieve the function pointer and then uses the function pointer to actually invoke the service. So, for example, when a call is made to NtCreateProcess, the system service dispatcher indexes into the system service table by using the NtCreateProcess service number. It then retrieves the function pointer that corresponds to that ID and invokes the NtCreateProcess service. For more information about how the operating system dispatches and executes system service calls, see Related topics at the end of this topic.
When a function pointer in the system service table is changed to point to the in-memory address of unknown code that was provided by a third party, the service dispatcher ultimately invokes the third-party code instead of the kernel code in question. Essentially, kernel patching bypasses actual Windows kernel code to invoke unknown third-party code. The third-party code might be attempting to provide some valid extension to Windows functionality, or it might be malicious.
Q: What problems are associated with kernel patching?
Patching fundamentally violates the integrity of the Windows kernel by replacing actual kernel code with unknown third-party code. As a result, patching introduces problems in three primary areas: reliability, performance and, most importantly, security.
- Reliability. The Windows kernel is tested extensively before any release of the operating system to ensure a high level of quality. Because patching replaces kernel code with unknown, untested code, there is no way to assess the quality or impact of the third-party code. Furthermore, kernel code is by its nature complex and critical to system stability, so bugs in unknown code can have a significant negative impact on system stability. An examination of Online Crash Analysis (OCA) data at Microsoft shows that system crashes commonly result from both malicious and non-malicious software that patches the kernel.
- Performance. Kernel performance is critical to the overall performance of the operating system. When low-level system calls are intercepted and unknown code is executed before control returns to the kernel, performance becomes unpredictable. Poorly designed unknown code can cause significant performance issues for Windows users.
- Security. Patching results in unknown code executing in kernel mode, so it is increasingly an avenue of attack by malicious software.
Q: Why was kernel patch protection implemented?
The primary motivation for implementing patch protection in Windows is to protect the integrity of the Windows kernel and, as a result, improve the overall reliability, performance, and security of Windows. The potential for patch protection to significantly increase the integrity and security of the Windows kernel makes this feature particularly important to current and future versions of Windows.
Q: Does patch protection prevent all viruses, rootkits, and other malware from attacking the system?
No. Patch protection eliminates one way to attack the system, by patching kernel images to manipulate kernel functionality. Protecting the integrity of the kernel is one of the most fundamental steps in protecting the entire system from malicious attacks and from inadvertent reliability problems that result from patching. However, it is not a panacea.
Q: What versions of Windows support patch protection?
Microsoft Windows Server 2003 with SP1 x64 and Windows XP x64 support kernel patch protection only for x64 hardware platforms. ("x64" refers to the 64-bit architecture that is used in AMD64 and Intel Extended Memory 64 Technology systems.) Kernel patch protection, only for x64-based platforms, is planned for future versions of Windows, including Microsoft Windows Vista and Microsoft Windows Server 2008.
Kernel patch protection is not currently supported for Intel Itanium hardware platforms or for 32-bit hardware platforms, but support on the platforms could change in the future.
Q: What happens if an application or driver attempts to patch the kernel on a system that supports patch protection?
If the operating system detects an application or driver that patches the kernel, it generates a bug check and shuts down the system. Modifications that trigger this behavior are:
- Modifying system service tables.
- Modifying the interrupt descriptor table (IDT).
- Modifying the global descriptor table (GDT).
- Using kernel stacks that are not allocated by the kernel.
- Patching any part of the kernel (detected only on AMD64-based systems).
Over time, patch protection will be extended to protect additional kernel resources.
Q: Is there any mechanism that allows a particular application or driver to patch the kernel?
No. There is no mechanism on systems that support patch protection that allows an application or driver to patch the kernel, for the following reasons:
- There is currently no reliable way for the operating system to distinguish between "known good" components and unknown components that might potentially be malicious. Therefore, it is not possible to grant patching capabilities only to "known good" components and deny them to unknown components.
- Even if "known good" components could be distinguished in a secure, non-spoofable, and reliable fashion from other components, patching would still introduce the reliability and performance issues that were described earlier. The attack surface of the kernel would also be increased to include the additional components.
Q: Is there any way to disable patch protection?
There is no way to disable patch protection, either for the system as a whole or selectively for a particular application or driver. However, patch protection is automatically disabled when a kernel debugger is attached to the system. This allows the kernel to be patched during a debugging session, for example, to enable setting breakpoints during the development, test, and diagnostic phase of kernel software development.
Q: Patch protection prevents my application or driver from running. What are my options?
Modify your application or driver to use only Microsoft-documented interfaces. If the functionality you want to enable is not supported with Microsoft-documented interfaces, then you cannot safely enable that functionality. There is no mechanism to selectively disable patch protection or "special-case" a given application to work around patch protection. If an application or driver patches the kernel, it generates a bug check and shuts down the system. Note that patch protection in the operating system might be extended in future releases or service packs, for example, addressing issues such as bugs, research findings, or black-hat hacking/bypassing of the system. Note that kernel patch protection has already received routine updates at least once since the first release, but the underlying enforcement policy has not changed since the first release. So, using any undocumented mechanisms or attempting to bypass patch protection in your application or driver (even if they seem to work on released versions of Windows that support patch protection) might result in further incompatibilities in the future.
If your application or driver must perform a task that you believe cannot be accomplished without patching the kernel, then contact KPPinput@Microsoft.com for help in finding a documented and supported alternative. The white paper that explains the criteria we are using to help evaluate and prioritize the types of APIs that will be developed and when they will be delivered can be found here (Kernel Patch Protection Criteria Evaluation Document).
Q: How does kernel patching relate to software updating/patching?
There may be some confusion around the term "patch" in "Kernel Patch Protection." Patching in the context of kernel patch protection refers specifically to modifications made directly to memory locations used for Windows operating system kernel code and data instead of calling through supported APIs to extend or change system functionality.
The term "patch" is used in a different context when we talk about releasing patches (otherwise referred to as updates) to fix software bugs. In general, all such patches are delivered as Microsoft signed files which are installed on the machine and then loaded into memory.
The former is used by potentially malicious software and third party vendors to change system behavior through untested and unsupported mechanisms.
The latter is a well tested process by which we deliver bug fixes to customers, for example, Microsoft providing an update to address an issue in the Windows operating system kernel.
Related topics
Kernel patch protection for x64-based operating systems
Microsoft® Windows® Internals, Fourth Edition: Windows 2000, Windows XP, and Windows Server 2003