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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 05 Aug 2011 13:23:48 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	luto@....edu, x86@...nel.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, lueckintel@...oo.com,
	kimwooyoung@...il.com
Subject: Re: New vsyscall emulation breaks JITs

On 08/05/2011 01:09 PM, Andi Kleen wrote:
> 
> Andy,
> 
> We found that your new vsyscall emulation in
> 
> commit 5cec93c216db77c45f7ce970d46283bcb1933884
> Author: Andy Lutomirski <luto@....EDU>
> Date:   Sun Jun 5 13:50:24 2011 -0400
> 
>     x86-64: Emulate legacy vsyscalls
> 
> breaks JITs that execute x86 code and use the legacy vsyscalls.
> 
> The problem is that the JIT translates the vsyscall page into
> its code buffer and executes the "int 0xcc" there. Then 
> when the kernel gets the interrupt it doesn't see the vsyscall
> page as the source and crashes the program.
> 
> For some reason several modern executables also seem
> to still use the old vsyscall page, so this problem can be hit
> quickly.
> 
> This happened with pin (http://www.pintool.org/), however
> I expect it will affect all user space x86 JITs (valgrind, 
> dynamo, qemu-user, etc.)
> 
> What to do? Right now this broke existing setups.
> 

I have to say I believe that trying to JIT the vdso or vsyscall pages is
extremely dubious at best.  They are fundamentally different from normal
user space in that the kernel can muck with them any time, without
notifying userspace about it.  The other aspect of this is that this is
about the legacy vsyscall page, which we're trying to get rid of, partly
because of security problems.

As such, it's not entirely obvious what the right thing to do here is.
On one hand, it "break user space" but on the other hand that is
userspace doing something fundamentally broken in the first place.

	-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/