Conclusion

Although PatchGuard version 2 introduces significant improvements in some areas, it still remains vulnerable to a wide variety of potential attacks. Additionally, it is possible (though involved) to subvert PatchGuard entirely, with the purpose of running arbitrary custom code in a difficult-to-detect manner in the place of PatchGuard.

With these points in mind, it is perhaps time to re-evaluate whether PatchGuard, in its current incarnation, is really worth all the trouble that Microsoft has put into it. Although forcing the IHV and ISV world to clean house with their kernel mode code is certainly a reasonable goal (and one which ultimately benefits all Windows customers, no matter how certain companies with poorly written kernel mode code [8] may care to spin the facts), as badly written kernel mode code results in the chronic instability that Windows is often associated with (at best), and privilege escalation and arbitrary code execution exploits in the worst case. However, there are still significant counterpoints to what PatchGuard represents; the fact that it may provide a convenient way for malicious kernel mode code to hide in a very difficult to detect manner, and that there is real innovation that is stifled by the restrictions that PatchGuard places on the system. As an example of the latter, consider that Microsoft's very own Virtual Server 2005 R2 SP1 (Beta) runs afoul of PatchGuard and requires a special kernel hotfix to alter what, exactly, PatchGuard protects in order to run without bugchecking the system with the infamous CRITICAL_STRUCTURE_CORRUPTION bugcheck made famous by PatchGuard [3]. This alone should be taken as an indicator that there are in fact legitimate uses for some of the techniques that PatchGuard prevents, despite Microsoft's insistence to the contrary. It should also be noted that despite Microsoft's statements that no exceptions would be made for PatchGuard [1], they have had to make adjustments at least once for their own code to run on PatchGuard. The conspiracy theorists among you might wonder whether Microsoft would be so gracious as to make such exemptions for legitimate uses of techniques blocked by PatchGuard for third party software with similar needs as Virtual Server 2005 R2 SP1, given their pointed statements to the contrary.

As a final note relating to the objectives of PatchGuard, even with hypervisor technology deployed (and furthermore, even with so-called immutable memory as implemented by a hypervisor), there is little that can be done to protect drivers from each other, as even in a hypervisor based system (where the kernel itself is protected from drvers), interdependent drivers will still be able to interfere with eachother so long as they co-exist in the same domain. This is particularly problematic in Windows, given the concepts of device stacks and device interfaces that allow drivers to directly interact with eachother in a variety of ways. It will be difficult to ensure that drivers do not resort to patching eachother (or modifying pool allocations instead of patching code, in the case where immutable memory on code regions is being enforced by a hypervisor). Depending on what the objectives of a third party ISV attempting to bypass PatchGuard are, it may be possible to simply patch drivers (such as Ntfs.sys or Tcpip.sys) in lieu of patching the kernel. From this perspective, it is unlikely that Windows will ever become an environment where kernel mode drivers are completely isolated and unable to interfere with eachother, despite the efforts of technologies such as PatchGuard.

Microsoft has already started down a path that may eventually lead to a system where buggy drivers will be unable to crash the system (or patch eachother), with the advent of the User Mode Driver Framework (UMDF). It remains to be seen whether isolated user-mode based drivers will become a viable alternative for high performance devices (such as PCI/PCI Express as opposed to USB devices), however, instead of simply being confined to a small subset of of the devices that ship with a typical computer. The author expects that whereever possible, Microsoft will attempt to move third party code outside of sensitive areas (like the kernel) and into more contained locations (such as a user-mode process). This is in-line with the purported goals of PatchGuard; increasing system stability by preventing third party drivers from performing questionable actions (or at least, questionable actions in such a way that might bring down the system).