Re: New vsyscall emulation breaks JITs

[Andrew Lutomirski]

On Fri, Aug 5, 2011 at 4:52 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> On Fri, Aug 05, 2011 at 01:48:28PM -0700, H. Peter Anvin wrote:
>> On 08/05/2011 01:45 PM, Andrew Lutomirski wrote:
>> >
>> > 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.
>> >
>>
>> How new does glibc have to be?
>
> Mine from May 17 doesn't support it.

c738465a4c13370f58b797a82cdf1c67e1121867 from May 28.

>
>> How much of a pain would it be to make the legacy vs emulated vsyscall
>> page a config option?
>
> CONFIG_DONT_BREAK_MY_BINARIES?
>

If gettimeofday could be a pure syscall fallback, then it wouldn't be
so bad.  With the vread_tsc changes, the vsyscall page can't directly
call ->vread anymore, and making *that* conditional would be rather
ugly.

> If anything runtime, but really for me it looks like the vsyscall
> changes should be only in one of those limited compability paranoia
> patchkits.

Switching it in runtime would be a giant mess because user code might
be executing from the vsyscall page while we try to switch it.
Switching at boot time might not be so bad.  We'd just compile the
emulation code in unconditionally but have a fallback page that we
could map if needed.

I also filed this issue:
https://code.google.com/p/dynamorio/issues/detail?id=530

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/