linux-kernel - Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary

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: <CA+55aFwPpYP5jfEyKuyq_yPDz8rxwxj-toTFOHxLtty-1hT1LA@mail.gmail.com>
Date:	Thu, 23 Apr 2015 16:04:50 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/asm/entry/32: Restore %ss before SYSRETL if necessary

On Thu, Apr 23, 2015 at 3:55 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> It's a matter of the ratio, right?  One cycle of syscall overhead
> saved is worth some number of context switch cycles added, and the
> ratio probably varies by workload.

Yeah. That said, I do think Peter is right that there are usually a
*lot* more system calls than there are context switches, even if I
guess you could come up with specific cases where that isn't true (eg
in-kernel file servers etc that never actually go to user space).

And the scheduler approach would have the benefit of not being in asm
code, so we can more easily use things like static keys or
alternative_asm() to make the overhead go away on CPU's that don't
need it. We certainly _can_ do that in an *.S file too, but we don't
have quite the same level of infrastructure help to do it.

Adding some static key protected thing to switch_to() in
arch/x86/kernel/process_64.c wouldn't seem too bad. And at that point,
the only cost is a a single no-op on most CPU's (we still don't know
_which_ AMD CPU's are affected, but I guess we could start off with
all of them and see if we can get an exhaustive list some way).

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