lkml.org 
[lkml]   [2011]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@MIT.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



\
 
 \ /
  Last update: 2011-08-05 22:27    [W:1.232 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site