From: Andi Kleen <andi@firstfloor.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andi Kleen <andi@firstfloor.org>,
tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, dwmw@amazon.co.uk, pjt@google.com,
luto@kernel.org, peterz@infradead.org, thomas.lendacky@amd.com,
tim.c.chen@linux.intel.com, gregkh@linux-foundation.org,
dave.hansen@intel.com, jikos@kernel.org
Subject: Re: x86/clearregs: Register sanitizing at kernel entry for speculation hygiene
Date: Tue, 9 Jan 2018 17:34:33 -0800 [thread overview]
Message-ID: <20180110013433.mmw7j3uy7xod5e25@two.firstfloor.org> (raw)
In-Reply-To: <50B38CB9-546E-4419-9162-D6A2AC2D80C3@amacapital.net>
> I don't like this at all. Once upon a time, Linux syscalls were supposed to be fast. Then we learned about the Meltdown screwup, so we mostly fixed it for real upstream and the distroa seriously half-arsed their own fixes [1]. This came with a big performance cost, but it can be turned off on non-busted hardware. So be it.
That's true, but modern CPUs are also a lot faster/wider than the K8
the fast path was originally designed for. A modern CPU can go through
these instructions really fast with a very high IPC because they don't have
dependencies or stalls.
So it shouldn't hurt very much.
Also in fact when the fast path was originally written the ABI still had a
different caller/callee split which made it more better. Later on
it already lost some of its benefits and was less of a win.
> But now we're proposing to throw out the whole fast path because it might make it a bit harder to do the most obvious attack. Not very hard, mind you, but a little bit harder. And there's no off switch for less-leaky hardware. No thanks.
Well the off switch is a fast CPU.
-Andi
next prev parent reply other threads:[~2018-01-10 1:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 1:03 Andi Kleen
2018-01-10 1:03 ` [PATCH v1 1/8] x86/entry/clearregs: Remove partial stack frame in fast system call Andi Kleen
2018-01-10 2:46 ` Brian Gerst
2018-01-11 0:16 ` Andi Kleen
2018-01-11 0:54 ` Brian Gerst
2018-01-11 1:02 ` Andi Kleen
2018-01-11 0:55 ` Andy Lutomirski
2018-01-11 1:01 ` Andi Kleen
2018-01-11 1:01 ` Brian Gerst
2018-01-11 1:22 ` Andy Lutomirski
2018-01-11 1:47 ` Andi Kleen
2018-01-11 18:44 ` Andi Kleen
2018-01-11 2:09 ` Josh Poimboeuf
2018-01-12 3:22 ` Josh Poimboeuf
2018-01-10 1:03 ` [PATCH v1 2/8] x86/entry/clearregs: Add infrastructure to clear registers Andi Kleen
2018-01-11 19:58 ` Konrad Rzeszutek Wilk
2018-01-11 20:10 ` Andi Kleen
2018-01-10 1:03 ` [PATCH v1 3/8] x86/entry/clearregs: Clear registers for 64bit SYSCALL Andi Kleen
2018-01-11 3:35 ` Brian Gerst
2018-01-11 18:47 ` Andi Kleen
2018-01-12 3:45 ` Josh Poimboeuf
2018-01-10 1:03 ` [PATCH v1 4/8] x86/entry/retpoline: Clear extra registers for compat syscalls Andi Kleen
2018-01-10 1:03 ` [PATCH v1 5/8] x86/entry/clearregs: Clear registers for 64bit exceptions/interrupts Andi Kleen
2018-01-10 1:23 ` Andy Lutomirski
2018-01-10 1:03 ` [PATCH v1 6/8] x86/entry/clearregs: Add number of arguments to syscall tables Andi Kleen
2018-01-10 1:26 ` Andy Lutomirski
2018-01-10 4:37 ` Andi Kleen
2018-01-10 20:05 ` Andy Lutomirski
2018-01-10 1:03 ` [PATCH v1 7/8] x86/entry/clearregs: Add 64bit stubs to clear unused arguments regs Andi Kleen
2018-01-10 1:03 ` [PATCH v1 8/8] x86/entry/clearregs: Clear registers for 32bit kernel Andi Kleen
2018-01-10 1:24 ` Andy Lutomirski
2018-01-10 1:16 ` x86/clearregs: Register sanitizing at kernel entry for speculation hygiene Andy Lutomirski
2018-01-10 1:34 ` Andi Kleen [this message]
2018-01-10 1:39 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180110013433.mmw7j3uy7xod5e25@two.firstfloor.org \
--to=andi@firstfloor.org \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=gregkh@linux-foundation.org \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®