Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall

[Stefan Weil <weil@mail.berlios.de>]

Laurent Desnogues schrieb:
> On Sun, Oct 18, 2009 at 5:09 AM, Jamie Lokier <jamie@shareable.org> wrote:
> [...]
>> Please don't do that.  Some code traces instructions through the
>> vsyscall/vdso page, and will be surprised if a syscall instruction
>> does not do what's expected based on the registers at that point.
>>
>> Also I don't know if anyone's done this, but I have played with the
>> idea of an optimising x86->x86 JIT translator (similar to valgrind or
>> qemu's TCG) which would include the vdso instruction sequence in it's
>> traces, just because it didn't treat that any differently from other
>> userspace code.  Making the syscall instruction behave differently due
>> to EIP would break that sort of thing.
>>
>> There's no performance penalty in setting a few registers prior to
>> using the syscall instruction normally, so please do that.
>
> My proposed patch intercepts vsyscall as soon as the PC is
> in the [VSYSCALL_START, VSYSCALL_END[ range, so all
> instructions in that range won't be translated. Doing it
> differently will cause problems due to the virtual address.
>
>> On x86_64, the vsyscall page has fixed address (see
>> linux/arch/x86/kernel/vsyscall_64.c), but the vdso usually has
>> variable address.
>>
>> On x86_32, the vdso has randomised address unless configurd to be a
>> fixed address.  On older kernels it was a fixed address and some
>> binary programs assume they can call that.
>
> So QEMU can't do things properly and some binaries will
> fail, right?
>
>
> Laurent

I can confirm that some binaries fail:

x86_64-linux-user/qemu-x86_64 ./bntest

with bntest from openssl creates a core dump.

Will Laurent's patch be applied, or is there a
better way to fix the problem?

Stefan