Re: New vsyscall emulation breaks JITs

[H. Peter Anvin]

On 08/09/2011 02:58 PM, Greg Lueck wrote:
> I apologize that Iâm just jumping into this conversation now.  I was
> swamped yesterday and this morning, and I only just started reading it
> today.
> 
> Pin needs to recognize all possible syscall trap instructions, so we
> will need to change our code to recognize INT 0xCC as a syscall trap. 

What you probably SHOULD be doing is to recognize the vsyscall/vdso as a
special chunk of memory.  The act of entering the vsyscall code is the
point where you need to intercept, if you're going to do that; relying
on the contents of the vsyscall/vdso page to have specific properties is
just plain broken, as you're "chasing the implementation", as well as
violate inherent properties of this particular memory space.

> SYSENTER instruction specially (on 32-bit).  When we see SYSENTER, Pin
> executes the syscall natively and then resumes JIT-compilation at the
> normal resume point in the gate area.  This works regardless of where
> Pin attaches to the application, and it also has the nice advantage that
> Pin tools see the exact sequence of user space instructions that the
> application would execute if it ran natively.

... and it's also complete bunk if you want any modicum of stability.
Keep in mind that the kernel can change the content of the vsyscall/vdso
memory at any time, without notifying userspace.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/