From: Paul Turner <pjt@google.com>
To: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linux-foundation.org>,
"Woodhouse, David" <dwmw@amazon.co.uk>,
Tim Chen <tim.c.chen@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Kees Cook <keescook@google.com>, Rik van Riel <riel@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@amacapital.net>,
Jiri Kosina <jikos@kernel.org>,
gnomes@lxorguk.ukuu.org.uk, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre")
Date: Thu, 4 Jan 2018 01:12:35 -0800 [thread overview]
Message-ID: <CAPM31RKSdWf4NtqYmCQJVWdbi+yERc0FTBFb9vX9dJ_Ro=x_wQ@mail.gmail.com> (raw)
In-Reply-To: <CAPM31RLaz7OuO_rm45_he=S0OZqPWY7zp-O6uevD25Br+YXwJA@mail.gmail.com>
On Thu, Jan 4, 2018 at 1:10 AM, Paul Turner <pjt@google.com> wrote:
> Apologies for the discombobulation around today's disclosure. Obviously the
> original goal was to communicate this a little more coherently, but the
> unscheduled advances in the disclosure disrupted the efforts to pull this
> together more cleanly.
>
> I wanted to open discussion the "retpoline" approach and and define its
> requirements so that we can separate the core
> details from questions regarding any particular implementation thereof.
>
> As a starting point, a full write-up describing the approach is available at:
> https://support.google.com/faqs/answer/7625886
>
> The 30 second version is:
> Returns are a special type of indirect branch. As function returns are intended
> to pair with function calls, processors often implement dedicated return stack
> predictors. The choice of this branch prediction allows us to generate an
> indirect branch in which speculative execution is intentionally redirected into
> a controlled location by a return stack target that we control. Preventing
> branch target injections (also known as "Spectre") against these binaries.
>
> On the targets (Intel Xeon) we have measured so far, cost is within cycles of a
> "native" indirect branch for which branch prediction hardware has been disabled.
> This is unfortunately measurable -- from 3 cycles on average to about 30.
> However the cost is largely mitigated for many workloads since the kernel uses
> comparatively few indirect branches (versus say, a C++ binary). With some
> effort we have the average overall overhead within the 0-1.5% range for our
> internal workloads, including some particularly high packet processing engines.
>
> There are several components, the majority of which are independent of kernel
> modifications:
>
> (1) A compiler supporting retpoline transformations.
> (1a) Optionally: annotations for hand-coded indirect jmps, so that they may be
> made compatible with (1).
> [ Note: The only known indirect jmp which is not safe to convert, is the
> early virtual address check in head entry. ]
> (2) Kernel modifications for preventing return-stack underflow (see document
> above).
> The key points where this occurs are:
> - Context switches (into protected targets)
> - interrupt return (we return into potentially unwinding execution)
> - sleep state exit (flushes cashes)
> - guest exit.
> (These can be run-time gated, a full refill costs 30-45 cycles.)
> (3) Optional: Optimizations so that direct branches can be used for hot kernel
> indirects. While as discussed above, kernel execution generally depends on
> fewer indirect branches, there are a few places (in particular, the
> networking stack) where we have chained sequences of indirects on hot paths.
> (4) More general support for guarding against RSB underflow in an affected
> target. While this is harder to exploit and may not be required for many
> users, the approaches we have used here are not generally applicable.
> Further discussion is required.
>
> With respect to the what these deltas mean for an unmodified kernel:
> (1a) At minimum annotation only. More complicated, config and
> run-time gated options are also possigble.
> (2) Trivially run-time & config gated.
> (3) The de-virtualizing of these branches improves performance in both the
> retpoline and non-retpoline cases.
>
> For an out of the box kernel that is reasonably protected, (1)-(3) are required.
>
> I apologize that this does not come with a clean set of patches, merging the
> things that we and Intel have looked at here. That was one of the original
> goals for this week. Strictly speaking, I think that Andi, David, and I have
> a fair amount of merging and clean-up to do here. This is an attempt
> to keep discussion of the fundamentals at least independent of that.
>
> I'm trying to keep the above reasonably compact/dense. I'm happy to expand on
> any details in sub-threads. I'll also link back some of the other compiler work
> which is landing for (1).
>
> Thanks,
>
> - Paul
next prev parent reply other threads:[~2018-01-04 9:13 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 9:10 [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre") Paul Turner
2018-01-04 9:12 ` Paul Turner [this message]
2018-01-04 9:24 ` Paul Turner
2018-01-04 9:48 ` Greg Kroah-Hartman
2018-01-04 9:56 ` Woodhouse, David
2018-01-04 9:30 ` Woodhouse, David
2018-01-04 14:36 ` [PATCH v3 01/13] x86/retpoline: Add initial retpoline support David Woodhouse
2018-01-04 18:03 ` Linus Torvalds
2018-01-04 19:32 ` Woodhouse, David
2018-01-04 18:17 ` Alexei Starovoitov
2018-01-04 18:25 ` Linus Torvalds
2018-01-04 18:36 ` Alexei Starovoitov
2018-01-04 19:27 ` David Woodhouse
2018-01-05 10:28 ` Paul Turner
2018-01-05 10:55 ` David Woodhouse
2018-01-05 11:19 ` Paul Turner
2018-01-05 11:25 ` Paul Turner
2018-01-05 11:26 ` Paolo Bonzini
2018-01-05 12:20 ` Paul Turner
2018-01-05 10:40 ` Paul Turner
2018-01-04 18:40 ` Andi Kleen
2018-01-05 10:32 ` Paul Turner
2018-01-05 12:54 ` Thomas Gleixner
2018-01-05 13:01 ` Juergen Gross
2018-01-05 13:03 ` Thomas Gleixner
2018-01-05 13:56 ` Woodhouse, David
2018-01-05 16:41 ` Woodhouse, David
2018-01-05 16:45 ` Borislav Petkov
2018-01-05 17:08 ` Josh Poimboeuf
2018-01-06 0:30 ` Borislav Petkov
2018-01-06 8:23 ` David Woodhouse
2018-01-06 17:02 ` Borislav Petkov
2018-01-07 9:40 ` David Woodhouse
2018-01-07 11:46 ` Borislav Petkov
2018-01-07 12:21 ` David Woodhouse
2018-01-07 14:03 ` Borislav Petkov
2018-01-08 21:50 ` David Woodhouse
2018-01-08 5:06 ` Josh Poimboeuf
2018-01-08 7:55 ` Woodhouse, David
2018-01-05 17:12 ` Woodhouse, David
2018-01-05 17:28 ` Linus Torvalds
2018-01-05 17:48 ` David Woodhouse
2018-01-05 18:05 ` Andi Kleen
2018-01-05 20:32 ` Woodhouse, David
2018-01-05 21:11 ` Brian Gerst
2018-01-05 22:16 ` Woodhouse, David
2018-01-05 22:43 ` Borislav Petkov
2018-01-05 22:00 ` Woodhouse, David
2018-01-05 22:06 ` Borislav Petkov
2018-01-05 23:50 ` Linus Torvalds
2018-01-06 10:53 ` Woodhouse, David
2018-01-04 14:36 ` [PATCH v3 02/13] x86/retpoline/crypto: Convert crypto assembler indirect jumps David Woodhouse
2018-01-04 14:37 ` [PATCH v3 03/13] x86/retpoline/entry: Convert entry " David Woodhouse
2018-01-04 14:46 ` Dave Hansen
2018-01-04 14:49 ` Woodhouse, David
2018-01-04 14:37 ` [PATCH v3 04/13] x86/retpoline/ftrace: Convert ftrace " David Woodhouse
2018-01-04 14:37 ` [PATCH v3 05/13] x86/retpoline/hyperv: Convert " David Woodhouse
2018-01-04 14:37 ` [PATCH v3 06/13] x86/retpoline/xen: Convert Xen hypercall " David Woodhouse
2018-01-04 15:10 ` Juergen Gross
2018-01-04 15:18 ` David Woodhouse
2018-01-04 15:54 ` Juergen Gross
2018-01-04 14:37 ` [PATCH v3 07/13] x86/retpoline/checksum32: Convert assembler " David Woodhouse
2018-01-04 14:37 ` [PATCH v3 08/13] x86/alternatives: Add missing \n at end of ALTERNATIVE inline asm David Woodhouse
2018-01-05 13:04 ` [tip:x86/pti] x86/alternatives: Add missing '\n' " tip-bot for David Woodhouse
2018-01-04 14:37 ` [PATCH v3 09/13] x86/retpoline/irq32: Convert assembler indirect jumps David Woodhouse
2018-01-04 14:37 ` [PATCH v3 10/13] x86/retpoline/pvops: " David Woodhouse
2018-01-04 15:02 ` Juergen Gross
2018-01-04 15:12 ` Woodhouse, David
2018-01-04 15:18 ` Andrew Cooper
2018-01-04 16:04 ` Juergen Gross
2018-01-04 16:37 ` Andi Kleen
2018-01-04 14:37 ` [PATCH v3 11/13] retpoline/taint: Taint kernel for missing retpoline in compiler David Woodhouse
2018-01-04 22:06 ` Justin Forbes
2018-01-04 14:37 ` [PATCH v3 12/13] retpoline/objtool: Disable some objtool warnings David Woodhouse
2018-01-04 14:37 ` [PATCH v3 13/13] retpoline: Attempt to quiten objtool warning for unreachable code David Woodhouse
2018-01-04 16:18 ` [RFC] Retpoline: Binary mitigation for branch-target-injection (aka "Spectre") Andy Lutomirski
2018-01-04 16:24 ` David Woodhouse
2018-01-05 10:49 ` Paul Turner
2018-01-05 11:43 ` Woodhouse, David
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='CAPM31RKSdWf4NtqYmCQJVWdbi+yERc0FTBFb9vX9dJ_Ro=x_wQ@mail.gmail.com' \
--to=pjt@google.com \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linux-foundation.org \
--cc=jikos@kernel.org \
--cc=keescook@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).