Lately, I have been playing with the new Microsoft hotpatch technology and my job consists on deploying hotpatch enabled fixes on test systems.  The hotpatching technology is intended to eliminate system downtime when installing critical security fixes onto systems. Currently this technology is available on 32-bit versions of Windows Server 2003 SP1. The idea is to extend support for the X64 and Itanium platforms. Hotpatching technology is planned to be part of Longhorn Sever and Vista SP1. Unfortunately this technology has its limitations; hotpatching cannot be applied to fixes that update the following components of the Windows OS:     

Win32k.sys: (kernel mode)

·         Exports windows “native” entry points

·         Implements Windows User & GDI  “native” functions; calls routines in GDI drivers

 

Ntoskrnl.exe: executive and kernel (both are in kernel mode)

The Executive includes:

·         base operating system services

·         memory management, process and thread management

·         security, I/O, interprocess communication

 

The kernel includes:

·         low-level operating system functions

·         thread scheduling, interrupt and exception dispatching

·         multiprocessor synchronization

·         provides a set of routines and basic objects that the rest of the executive uses 

          to implement higher-level constructs

 

Both are contained in file Ntoskrnl.exe

 

Kernel32.dll: One of the WINAPI DLLs (user mode)

·         Exports the APIs defined by the subsystem

 

Managed code (user mode)

 

According to Microsoft this is how a hotpatch package works:

The hotpatch package contains coldpatch and hotpatch binaries for the fix. The hotpatch binary only contains the updated function, function that needs to change to address critical OS flaw. The updated function, as a hotpatch binary, gets inserted into the loaded image of the defective binary. A jump instruction is inserted above the defective function to redirect all subsequent calls to the updated function.

The coldpatch contains the old binary with the fixed function appended to it and a jump instruction instrumented bypassing the flawed function to the fixed function. Hotpatch application addresses currently running instances of the critical flaws in all the process and the complementing cold patch secures the new instances of the process and persists the patch beyond reboot.

Thus the package containing a hotpatch enabled fix will have two binaries related to file being serviced. One with the “.hp.” in its name is the hotpatch binary and the other one is the coldpatch binary.