Runtime Code Patching - Not for the Faint of Heart

re: Runtime Code Patching - Not for the Faint of Heart

molotov — Thu, 15 May 2008 04:47:00 GMT

Nice post, Jonathan - thanks for explaining in a clear, concise fashion the issues revolving around this.

re: Runtime Code Patching - Not for the Faint of Heart

eranb — Thu, 15 May 2008 07:52:47 GMT

Very interesting post.

Can you further elaborate on the caching issues involved? Also, why do we need to corral all running threads? Do we care if a thread is now running inside the old function?

Thanks,

Eran.

re: Runtime Code Patching - Not for the Faint of Heart

theelvez — Thu, 15 May 2008 09:01:25 GMT

Thanks for the comments molotov and Eran!

Eran - here is one example of a cache issue with the instruction cache (from the Intel IA32 Processors Manuals):

"For Intel486 processors, a write to an instruction in the cache will modify it in both

the cache and memory, but if the instruction was prefetched before the write, the old

version of the instruction could be the one executed. To prevent the old instruction

from being executed, flush the instruction prefetch unit by coding a jump instruction

immediately after any write that modifies an instruction."

There are other processor dependent issues as well, but they all revolve around the fact that entry points into the new instruction op code can exist when the caches and memory get out of sync. Thanks!

re: Runtime Code Patching - Not for the Faint of Heart

theelvez — Thu, 15 May 2008 09:04:49 GMT

Eran - also about your second point - right - we don't care if someone was already passed that patch area - we just need to manage the accesses to the area around the patch. Thanks.

re: Runtime Code Patching - Not for the Faint of Heart

theelvez — Sat, 17 May 2008 18:56:05 GMT

Daniel Pearson pointed out an error in my post that I want to share with everyone. I led you to believe (from my example disassembly at the end of the post) that the 5 bytes of nop opcode that get overwritten are at the end of the function. They are not - they are actually the 5 bytes preceding the function. It makes totally sense when you think about it - because the 2 byte jump instruction can only jmp 127/128 bytes in either direction respectively. Why is this important? Well if you had a function that was larger than 127 bytes you couldn't reach your nop patch bytes if they were at the end! :)

It is a subtle but very important point. Thanks Daniel!

re: Runtime Code Patching - Not for the Faint of Heart

Eternal Idol — Fri, 23 May 2008 11:50:19 GMT

The mov edi, edi is used by Microsoft Hotpatching.

re: Runtime Code Patching - Not for the Faint of Heart

clark.li — Wed, 30 Jul 2008 09:05:30 GMT

>> So what is the moral of the story here? Don’t patch code? Well that may be a little extreme, but the moral is at least to never patch multiple instructions.

I think that's not enough. I saw the detour library by M$ used CopyMemory to copy op bytes, where CopyMeomory was finally spread to

rep movsd;

So even you just want to copy one single instruction, there is also possiblity that another thread gets CPU before all bytes are copied. (Also consider multi-core processor)

re: Runtime Code Patching - Not for the Faint of Heart

Eternal Idol — Wed, 30 Jul 2008 16:38:38 GMT

Sure but that could be easily fixed using instructions like cmpxchg8b.

re: Runtime Code Patching - Not for the Faint of Heart

awana81 — Thu, 28 Aug 2008 16:42:49 GMT

How does the detours library handle the caching issue?

re: Runtime Code Patching - Not for the Faint of Heart

zhzhtst — Wed, 10 Sep 2008 15:30:27 GMT

Great! Can you describe more detail about "Hot Patch" technology?