Bug 135491

Summary: vex x86->IR: unhandled instruction bytes: 0xCD 0x1 0x90 0x90
Product: [Developer tools] valgrind Reporter: acahalan
Component: vexAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: crash    
Priority: NOR    
Version: 3.2.1   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Bug Depends on:    
Bug Blocks: 256630    

Description acahalan 2006-10-12 09:01:54 UTC
Version:           3.2.1 (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

This is the "int 0x01" instruction. It needs to be executed in a way that causes a proper signal. Right now I'm seeing SIGILL, and I expect other problems.

"proper" being:

a. correct signal (Linux uses SIGSEGV, not SIGILL)
b. correct eip in ucontext (at beginning or end of instruction as appropriate)
c. obey sigaltstack stuff
d. correct err in ucontext
e. the rest of ucontext all correct too
f. signal mask in the signal handler is correct
g. correct type of signal handler (SA_SIGINFO or not)
h. return from signal handler, if any, obeys ucontext changes

BTW, do not forget: "int1" a.k.a. "icebp" (opcode 0xf1), "int3" (opcode 0xcc), "int 0x03" (opcode 0x80 0x03), "into", "bound"...
Comment 1 acahalan 2006-10-12 09:17:25 UTC
BTW, it's not "KDE Devel" at all, but I was forced to pick something. I don't have KDE installed.
Comment 2 Tom Hughes 2006-10-12 09:40:43 UTC
Wat made you pick KDE Devel? Did you use the generic KDE bug reporting page? or did you use the valgrind one?
Comment 3 Tom Hughes 2006-10-12 09:44:10 UTC
Why do you expect other problems? I agree that we don't raise the right signal for various int instructions, but as far as I know (b), (c), (f) and (g) are all correct.

I believe that (e) and (h) are largely correct, at least for integer registers - there may be issues with floating point registers though, especially for (h).

I believe there may be some issues with (d) but it is far more likely to be correct if the signal is correct.
Comment 4 acahalan 2006-10-12 10:02:38 UTC
Regarding Comment #2: I followed the link from the valgrind page, was made to create an account (which sucks), couldn't log in immediately, then later returned to whatever page that was. It was some "wizard" interface.

Regarding Comment #3: It's a bit scary that you don't just jump to the real code. That would be the obvious way to get 100% correct signal frames. I've also seen problems using sigqueue() and longjmp(), but I don't have the testcase handy.
Comment 5 Tom Hughes 2006-10-12 10:11:13 UTC
I suspect you wound up back at the generic KDE page because you had to go through the account creation - it's a bit of a limitation of the way we are borrowing space in the KDE bug tracker I'm afraid. It shouldn't happen next time as you have an account now...

We don't jump to the real code because the real code is in the kernel so we can't! Your program is running on an emulated virtual machine so we have to do many of the things the kernel would normally do on behalf of your emulated process.

So the kernel delivers a signal to us (or sometimes, like here, we actually fake the signal ourselves when we encounted an instruction that should generation a signal. We then build a ucontext containg the emulated register values (which I am sure you would prefer to the real register values...) and then run your signal handler under emulation on the virtual machine.
Comment 6 acahalan 2006-10-12 12:07:59 UTC
By "jump to the real code" I do not mean the kernel code. I mean the untranslated app code at the original memory location, causing a real trap into the kernel from the correct location.

I presume you would then catch this on your own stack, copy the stack frame over to the app stack, and continue on with emulation at the app's signal handler code.

This way you wouldn't need to built a ucontext yourself, possibly excepting a few adjustments in the stack_t to indicate sigaltstack-related status. (and relocation for stuff like the FPU data pointer of course)
Comment 7 Tom Hughes 2006-10-12 12:20:20 UTC
Because that's an incredibly complicated and fragile looking solution. Without thinking very hard about it I have no idea whether or not it could be made to work, but it's largely pointless as we have a perfectly good signal delivery mechanism already.

Fixing this bug is not rocket science, it just needs a bit of VEX work from Julian to make VEX correctly indicate what signal needs to be raised and valgrind is perfectly capable of doing everything else already.

It is possible that there might be some problems with the signal frames we create, but those will be fairly easy to fix if they do turn out to be a problem for you and I think we're getting way ahead of ourselves to worry about them now.