One of the most dreadful scenarios for critical computers is a persistent kernel-level system error, leaving the computer in a BSOD (blue screen of death) loop that is usually impossible to resolve remotely. In such case, an admin must boot the computer in safe mode (which doesn't run 3rd-party kernel drivers) and do whatever it takes to resolve the error. This usually means disabling an offending kernel driver, deleting files that are triggering the error, or changing some configuration. Scenarios like this have been happening on various scales since the computers were invented. By far the most globally impactful was when a CrowdStrike update persistently crashed their kernel driver in July 2024, grounding airlines, cloud services, banking, emergency services and many other services worldwide.
Users' concerns about 3rd-party kernel code in vendors' products are therefore quite reasonable.
0patch Agent does include a small kernel driver (0patchDriver32.sys or 0patchDriver64.sys, registered under name "0patchDriver"). It is there for one single purpose: detecting when a new user space process is launched and loading our DLL into such process. 0patch Agent is a stable application and we rarely need to update it (it's typically 18-24 months between releases), and although it by default updates automatically, you can have full control of the update process in an Enterprise account and can also update it in stages to further contain the risk.
Furthermore, our kernel driver does not process data that isn't already there at the installation time; specifically, the kernel driver does not process our subsequently delivered patches in any way (these are loaded and applied by our DLL that is loaded in user space processes).
The minimal and "static" nature of our kernel driver minimizes (but of course not entirely removes) the risk of kernel failure, making it very unlikely that a BSOD would occur on a customer's system without also having occurred on our testing computers. There can always be an unfortunate interaction between our kernel driver and some component from another 3rd-party vendor, but that should likely be discovered on customer's testing systems.
We will continue exercising utmost caution in developing and testing 0patch Agent. We understand 0patch is being used in highly critical environments and are committed to not only providing a product that requires no restart upon installation or removal, or upon applying or un-applying individual patches, but also one that causes minimal unexpected problems (in kernel or user space).
0 Comments