Messages in this thread | | | Date | Tue, 26 Aug 2008 10:32:30 -0700 | From | "H. Peter Anvin" <> | Subject | Re: 2.6.{26.2,27-rc} oops on virtualbox |
| |
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.
| |