linux-kernel - Re: New vsyscall emulation breaks JITs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 09 Aug 2011 15:59:38 -0500
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Greg Lueck <lueckintel@...oo.com>
CC:	Andrew Lutomirski <luto@....edu>, Andi Kleen <andi@...stfloor.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"kimwooyoung@...il.com" <kimwooyoung@...il.com>
Subject: Re: New vsyscall emulation breaks JITs

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/