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_7G2TqBVXvfuh2GPNteYBNoc8_s398KS+jPOPQYAhPHz0Q@mail.gmail.com>
Date:	Fri, 5 Aug 2011 17:00:44 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, 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:52 PM, Andi Kleen <andi@...stfloor.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/