The fate of "hot patching" (DUKS) and a new way of doing it
By jimmo on Aug 05, 2004
Way back when Solaris 8 was being developed, I came up with a way to dynamically revector the flow of execution in a running kernel. This idea came about because a large number of the bug fixes we were producing for customers were fairly simple...not all of them but quite a few. Customers were being forced to install new kernel binaries and reboot to verify our fixes, which introduced additional delay into the time it takes us to produce a patch.
By being able to load a replacement bit of code (via the loadable module mechanism) and revectoring the execution flow, we could allow our customers to try out the fix without having to wait for their next scheduled downtime. Sadly, it was never possible to do this for formal patches because the dependencies in the patches were invariably too extensive. That's ok, because it was only really intended to get a preliminary bug fix or diagnostic code change into a live kernel quickly.
One of the biggest problems with implementing something like this is that the architectural design of the operating system software needs to have this facility designed in. There are a number of ways to try and "retrofit" the capability but none of them really work very well.
Anyway, that got me thinking about how we could implement such a facility from scratch - should we ever get the chance. Well, last December I was implementing a VM layer on an toy x86 operating system I was writing at home and it occurred to me that we could use a similar method to the way address translation is performed with page tables and apply it to this problem. In fact, it wouldn't take a huge leap of technology to hardware accelerate the translation process from 32-bit code to function (method) address because the ability to walk software maintained tables is already in the hardware. Woohoo! A high performance dynamically updateable software architecture!
I've had a paper on this published via the Research Disclosure Database so rather than go into detail here, if you're interested just read the paper.