If somebody tries to hot-patch an already-hot-patched function

Interesting framing that hooking functions is considered “rogue” by Microsoft, or something you’re “not authorized” to do, when Microsoft themselves makes the detours library and never framed it like this before.

Also, missing from this explanation: hooks are usually applied per process, from user space. The code pages in a dynamic library are CoW’d from the shared page when you write to them to apply a patch.

Does the Windows Update work similarly, or does it somehow modify the original, shared page, affecting all processes? Does a hook in a single process disable hot patching on the entire system?

At a previous job I wrote a docker build for patching individual Java class files on top of a monolithic docker image. This was not runtime patching, but allowed a single layer that was only a few kilobytes to be deployed quickly in emergency situations.

Interestingly, it had similar constraints and checked them at build time: it could not be a public ABI change and only one patch at a time.

The world could use more hot patching. Now that AI upends computer security, getting software patched in a timely fashion is more important than ever, and having to reboot/restart the process or computer to get those updates is more of a problem than it was before.

Windows parallel DLL loading also defensively disables itself for a process if it finds some NT DLL functions have been hooked https://stackoverflow.com/questions/42789199/why-there-are-t...

So much effort to reinvent half of Common Lisp. They haven’t gotten to the part where redefining a class causes all existing class instances to be lazily upgraded to the new class layout.

If your hotpatching library is competent, then it does everything atomically. Either by suspending all threads first and temporarily resuming them while they're executing any affected instructions, or by just using atomics when possible.

In which case there is no race condition.

What happens if two consecutive updates try to hot patch the same function? Wouldn’t this be completely within the realm of possibility and be a pure Microsoft issue with no one else involved?

Detouring can be done for already detoured functions. Just look at Steam Overlay vs other systems that hook into Direct3D, they can coexist.

It's been at least 20 years, and Microsoft's blogging platform still doesn't support previous/next post links. Makes it goddamn hard to read the prior series about hot patching if it's not at the top of the blog.

>There is a race condition: The prescan may show that all the functions are safe to patch, but then somebody might patch a function after the prescan completes. In that case, the patcher will get halfway through and then discover the rogue-patched function, and now it’s kind of stuck. It can’t continue forward, and it can’t reliably roll back (because the rollback is probably also going to fail because the patch got overpatched). You’re stuck with a binary in memory that is half-patched, and who knows what’ll happen now.

Ehh :) scenarios like this are the best

It’s like mixing two different hot sauces, ymmv.