I have been unable to replicate this on my own hardware mostly because
my testing machine decided to blow its DVD drive in some very strange
way, but I did pick apart the data from Luiz, and found it very interesting:
The code sequence before patching looks like:
c012fc69: 51 push %ecx
c012fc6a: 52 push %edx
c012fc6b: ff 15 40 b9 41 c0 call *0xc041b940
c012fc71: 5a pop %edx
c012fc72: 59 pop %ecx
After patching:
50 9d 0f 1f 84 00 00 00 <00> 00
... which disassembles to (in Intel notation):
C012FC69 50 push eax
C012FC6A 9D popfd
C012FC6B 0F1F840000000000 nop dword [eax+eax+0x0]
We do, indeed have a return point that falls in the *middle* of a
patched instruction, and if the patching happens in the middle of the
instruction call, then, well, bad things happen.
Furthermore, why on Earth is %ecx/%edx pushed and popped in-line here?
Surely it should be the responsibility of the PV call to present a
no-clobber interface (using an assembly wrapper if necessary[*]), rather
than bloating every callsite like this?
-hpa
[*] One can compile gcc code with -fcall-saved-* to use nonstandard
register conventions. Unfortunately stock gcc only lets you do this
with a file parameter, and doesn't support doing this with attributes.
--
