linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: tglx@linutronix.de
Cc: x86@kernel.org, dwmw@amazon.co.uk, linux-kernel@vger.kernel.org,
	pjt@google.com, torvalds@linux-foundation.org,
	gregkh@linux-foundation.org, peterz@infradead.org,
	luto@amacapital.net, thomas.lendacky@amd.com,
	arjan.van.de.ven@intel.com, Andi Kleen <ak@linux.intel.com>
Subject: [PATCH 2/4] x86/retpoline: Avoid return buffer underflows on context switch
Date: Fri, 12 Jan 2018 10:45:48 -0800	[thread overview]
Message-ID: <20180112184550.6573-3-andi@firstfloor.org> (raw)
In-Reply-To: <20180112184550.6573-1-andi@firstfloor.org>

From: Andi Kleen <ak@linux.intel.com>

CPUs have return buffers which store the return address for
RET to predict function returns. Some CPUs (Skylake, some Broadwells)
can fall back to indirect branch prediction on return buffer underflow.

With retpoline we want to avoid uncontrolled indirect branches,
which could be poisoned by ring 3, so we need to avoid uncontrolled
return buffer underflows in the kernel.

This can happen when we're context switching from a shallower to a
deeper kernel stack.  The deeper kernel stack would eventually underflow
the return buffer, which again would fall back to the indirect branch predictor.

The other thread could be running a system call trigger
by an attacker too, so the context switch would help the attacked
thread to fall back to an uncontrolled indirect branch,
which then would use the values passed in by the attacker.

To guard against this fill the return buffer with controlled
content during context switch. This prevents any underflows.

This is only enabled on Skylake.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 arch/x86/entry/entry_32.S | 14 ++++++++++++++
 arch/x86/entry/entry_64.S | 14 ++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index a1f28a54f23a..bbecb7c2f6cb 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -250,6 +250,20 @@ ENTRY(__switch_to_asm)
 	popl	%ebx
 	popl	%ebp
 
+	/*
+	 * When we switch from a shallower to a deeper call stack
+	 * the call stack will underflow in the kernel in the next task.
+	 * This could cause the CPU to fall back to indirect branch
+	 * prediction, which may be poisoned.
+	 *
+	 * To guard against that always fill the return stack with
+	 * known values.
+	 *
+	 * We do this in assembler because it needs to be before
+	 * any calls on the new stack, and this can be difficult to
+	 * ensure in a complex C function like __switch_to.
+	 */
+	FILL_RETURN_BUFFER %ecx, RSB_FILL_LOOPS, X86_FEATURE_RETURN_UNDERFLOW
 	jmp	__switch_to
 END(__switch_to_asm)
 
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 59874bc1aed2..3caac129cd07 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -495,6 +495,20 @@ ENTRY(__switch_to_asm)
 	popq	%rbx
 	popq	%rbp
 
+	/*
+	 * When we switch from a shallower to a deeper call stack
+	 * the call stack will underflow in the kernel in the next task.
+	 * This could cause the CPU to fall back to indirect branch
+	 * prediction, which may be poisoned.
+	 *
+	 * To guard against that always fill the return stack with
+	 * known values.
+	 *
+	 * We do this in assembler because it needs to be before
+	 * any calls on the new stack, and this can be difficult to
+	 * ensure in a complex C function like __switch_to.
+	 */
+	FILL_RETURN_BUFFER %r8, RSB_FILL_LOOPS, X86_FEATURE_RETURN_UNDERFLOW
 	jmp	__switch_to
 END(__switch_to_asm)
 
-- 
2.14.3

  parent reply	other threads:[~2018-01-12 18:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 18:45 Improve retpoline for Skylake Andi Kleen
2018-01-12 18:45 ` [PATCH 1/4] x86/retpoline: Add new mode RETPOLINE_UNDERFLOW Andi Kleen
2018-01-12 22:13   ` Dominik Brodowski
2018-01-12 22:57     ` Andi Kleen
2018-01-12 18:45 ` Andi Kleen [this message]
2018-01-12 18:45 ` [PATCH 3/4] x86/retpoline: Fill return buffer after idle Andi Kleen
2018-01-12 18:45 ` [PATCH 4/4] x86/retpoline: Fill return buffer on interrupt return to kernel Andi Kleen
2018-01-12 19:12 ` Improve retpoline for Skylake David Woodhouse
2018-01-12 19:21   ` Andi Kleen
2018-01-12 22:03     ` Henrique de Moraes Holschuh
2018-01-15  8:26       ` Jon Masters
2018-01-15  9:06         ` David Woodhouse
2018-01-15 10:03         ` Thomas Gleixner
2018-01-15 10:20           ` David Woodhouse
2018-01-15 16:57         ` Andy Lutomirski
2018-01-15 17:38           ` Andrew Cooper
2018-01-15 17:56             ` Van De Ven, Arjan
2018-01-15 18:06             ` Andy Lutomirski
2018-01-15 18:07               ` David Woodhouse
2018-01-15 18:10                 ` 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=20180112184550.6573-3-andi@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=ak@linux.intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.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;
as well as URLs for NNTP newsgroup(s).