Hotpatching a C Function on x86

Re:Hotpatching a C Function on x86 by openasocket on Friday April 01, 2016 @01:32PM (#11406730)

Question: what if you just had some global function pointer that you would call instead, so hotpatching would just involve changing the pointer? That seems a lot simpler, there's less that can go wrong, and is a lot more portable. I get that this would probably be slower for the caller, but it's not that much slower. If the function is in the hot path that function pointer will be in cache anyway, so how slow is that read compared to the 8-byte NOP? It sounds to me like the OPs code will only be a cycle or two faster for each call during normal execution. Maybe I'm forgetting something.

[ Parent | on HN ]

Re:Hotpatching a C Function on x86 by munin on Friday April 01, 2016 @01:41PM (#11406804)

it winds up being about the same. you need a pointer-wide atomic compare-and-swap (CAS) to swap out the function pointer safely.

on x86_64, a pointer-wide value is 8 bytes, which is enough space to put some instructions that detour to another function. so it's a question of whether you CAS the global function pointer, or the first 8 bytes of the function.

the "atomic CAS" part means you don't benefit from caching either, since you need to make sure the write is globally visible or threads on different cores will do different things. this kind of trickery combines two terrible things: reasoning about virtual method invocation (essentially) and lock-free programming techniques. have fun!

[ Parent | on HN ]

Re:Hotpatching a C Function on x86 by openasocket on Friday April 01, 2016 @03:20PM (#11407740)

Why do you need a CAS? Isn't an atomic write sufficient? Because we're just changing the function to use our code we don't really care what it was pointing to before, and we don't care if someone else changed the pointer before we did: it's just last write wins. In fact, the function pointer method will be able to have multiple threads try to hotpatch at once; idk about the OP code.

My guess is the OP's method can probably be extended to allow for more advanced hooking, like returning to the original function definition after running the new code or something. And, it means the caller doesn't have to know that the function is hot patchable, which I'm guessing is the most likely reason.

[ Parent | on HN ]