linux-kernel - Re: [patch] x86/vsyscall: Add Kconfig option to use native vsyscalls, switch to it

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: <CALCETrVVQXbHvWaT9HLHgk6cbMT9EHGrsGJptVS+66OMDmnGYA@mail.gmail.com>
Date:	Tue, 20 Nov 2012 15:01:13 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	David Rientjes <rientjes@...gle.com>, Mel Gorman <mgorman@...e.de>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>
Subject: Re: [patch] x86/vsyscall: Add Kconfig option to use native vsyscalls,
 switch to it

On Tue, Nov 20, 2012 at 1:41 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Ingo Molnar <mingo@...nel.org> wrote:
>
>> >      0.10%  [kernel]          [k] __do_page_fault
>> >      0.08%  [kernel]          [k] handle_mm_fault
>> >      0.08%  libjvm.so         [.] os::javaTimeMillis()
>> >      0.08%  [kernel]          [k] emulate_vsyscall
>>
>> Oh, finally a clue: you seem to have vsyscall emulation
>> overhead!
>>
>> Vsyscall emulation is fundamentally page fault driven - which
>> might explain why you are seeing page fault overhead. It might
>> also interact with other sources of faults - such as
>> numa/core's working set probing ...
>>
>> Many JVMs try to be smart with the vsyscall. As a test, does
>> the vsyscall=native boot option change the results/behavior in
>> any way?
>
> As a blind shot into the dark, does the attached patch help?
>
> If that's the root cause then it should measurably help mainline
> SPECjbb performance as well. It could turn numa/core from a
> regression into a win on your system.
>
> Thanks,
>
>         Ingo
>
> ----------------->
> Subject: x86/vsyscall: Add Kconfig option to use native vsyscalls, switch to it
> From: Ingo Molnar <mingo@...nel.org>
>
> Apparently there's still plenty of systems out there triggering
> the vsyscall emulation page faults - causing hard to track down
> performance regressions on page fault intense workloads...
>
> Some people seem to have run into that with threading-intense
> Java workloads.
>
> So until there's a better solution to this, add a Kconfig switch
> to make the vsyscall mode configurable and turn native vsyscall
> support back on by default.
>

I'm not sure the default should be changed.  Presumably only a
smallish minority of users are affected, and all of their code still
*works* -- it's just a little bit slower.

>
> +config X86_VSYSCALL_COMPAT
> +       bool "vsyscall compatibility"
> +       default y
> +       help

This is IMO misleading.  Perhaps the option should be
X86_VSYSCALL_EMULATION.  A description like "compatibility" makes
turning it on sound like a no-brainer.

Perhaps the vsyscall emulation code should be tweaked to warn if it's
getting called more than, say, 1k times per second.  The kernel could
log something like "Detected large numbers of emulated vsyscalls.
Consider upgading, setting vsyscall=native, or adjusting
CONFIG_X86_WHATEVER."


> +         vsyscalls, as global executable pages, can be a security hole
> +         escallation helper by exposing an easy shell code target with

escalation?

> +         a predictable address.
> +
> +         Many versions of glibc rely on the vsyscall page though, so it
> +         cannot be eliminated unconditionally. If you disable this
> +         option these systems will still work but might incur the overhead
> +         of vsyscall emulation page faults.
> +
> +         The vsyscall=none, vsyscall=emulate, vsyscall=native kernel boot
> +         option can be used to override this mode as well.
> +
> +         Keeping this option enabled leaves the vsyscall page enabled,
> +         i.e. vsyscall=native. Disabling this option means vsyscall=emulate.
> +
> +         If unsure, say Y.
> +

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