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]

Message-ID: <CAObL_7E3yOHtx9N3qd2UXVn+h6tACoNjekRhiMcHrzb=Mu4q8A@mail.gmail.com>
Date:	Fri, 5 Aug 2011 16:45:02 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>, 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 Fri, Aug 5, 2011 at 4:23 PM, H. Peter Anvin <hpa@...or.com> wrote:
> 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.

Valgrind in particular is already smart enough not to JIT
gettimeofday().  It crashes on the getcpu vsyscall with or without the
vsyscall emulation patch, so we get off easy there.  (I haven't tried
to debug it.)

I suspect that qemu-user won't have this problem either because I
doubt it looks into the vsyscall page in the first place.  Presumably
it just maps the original program.  In any case, it's a full emulator,
and I don't see why the host kernel should matter.

I'm a bit disinclined to play with Pin, because the license tells me
that I shouldn't reverse-engineer anything, and that would be the
whole point.  It claims to be pre-release code.

If by dynamo you mean DynamoRIO, I can't get it to build.

An older version of the vsyscall emulation code used a fancier
sequence that would survive relocation, although it involved a 'ret'
instruction and it would be nice not to put 'ret' into the vsyscall
page.

hpa: time is supported (as of 3.0) by the vdso, and very new glibc
uses the vdso version.  We could add a native time implementation back
to the vsyscall page without too much pain as a short-term fix, but
that would be less than ideal.

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