BRONZE PARTNER:
BRONZE PARTNER:
Industry News:
| |
| |
|
|
|
|
|
| Microsoft's Hotpatching Technology |
|
|
|
By: Steve Thompson
Posted On: 12/1/2006
Have you ever needed to apply a security update to a server, but could not reboot the server it since it was providing a critical function? Database and Exchange servers come to mind. In our environment we have a formal change review process that requires management approval. So, it's not always possible to quickly update and reboot our more critical servers, which in turn leaves them potentially vulnerable. Enter "hotpatching".
The "hotpatching" technology was announced earlier this year. It seemed to offer a lot of promise, the ability to immediately and dynamically apply a security update to a server without rebooting. Then, apply the "normal" security update that takes effect on the next recycle. After not hearing anything additional on this subject, I sent an inquiry to one of my contacts at Microsoft about the current status of this technology. It shows a lot of promise, however is still lacking in some ways -- I expect some major improvements as the operating system technologies improve.
Thought you'd be interested in the response:
~~~~~~~~~~~~~~~~~
Microsoft as a whole is adopting this technology broadly, but due to development cycles per product, it will realistically take years to show up in every single product. Perhaps the best write-up at this stage is on one of our tester's blogs, where he candidly lays out the "real-world" limits of the technology, as well as discusses the value of the technology:
http://www.msblog.org/2006/03/27/microsoft-hotpathcing-beta
Key excerpts from this site to note:
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 long-term goal 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.
|
|
|
|
|
|
