From: "Woodhouse, David" <dwmw@amazon.co.uk>
To: Boris Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
"Thomas.Lendacky@amd.com" <Thomas.Lendacky@amd.com>
Cc: "ak@linux.intel.com" <ak@linux.intel.com>,
"tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"x86@kernel.org" <x86@kernel.org>,
"riel@redhat.com" <riel@redhat.com>,
"keescook@google.com" <keescook@google.com>,
"gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
"pjt@google.com" <pjt@google.com>,
"Ghitulete, Razvan-alin" <rga@amazon.com>,
"dave.hansen@intel.com" <dave.hansen@intel.com>,
"luto@amacapital.net" <luto@amacapital.net>,
"jikos@kernel.org" <jikos@kernel.org>,
"gregkh@linux-foundation.org" <gregkh@linux-foundation.org>
Subject: Re: [PATCH] x86/retpoline: Fill return stack buffer on vmexit
Date: Thu, 11 Jan 2018 09:07:08 +0000 [thread overview]
Message-ID: <1515661628.22302.294.camel@amazon.co.uk> (raw)
In-Reply-To: <1F5F831F-0C4B-4DA9-8A48-D0D1C1ADC0D7@alien8.de>
[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]
On Thu, 2018-01-11 at 09:49 +0100, Boris Petkov wrote:
> On January 11, 2018 9:42:38 AM GMT+01:00, Peter Zijlstra wrote:
> >Or we teach the alternative thing to patch in a jmp to end instead of
> >NOP padding the entire thing as soon as the jmp (3 bytes) fits ?
>
> Or, even better: use alternative_call() to call functions instead of patching gazillion bytes.
For this one I kind of wanted to keep it as a macro so we can select
which register it uses. I've taken the bulk of it out of the
ALTERNATIVE, and just switch between the first 'mov' instruction and a
jmp over the whole lot.
Looks like this now...
From 302622182f56825b7cf2c39ce88ea8c462d587fe Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@amazon.co.uk>
Date: Wed, 10 Jan 2018 22:32:24 +0000
Subject: [PATCH] x86/retpoline: Fill return stack buffer on vmexit
In accordance with the Intel and AMD documentation, we need to overwrite
all entries in the RSB on exiting a guest, to prevent malicious branch
target predictions from affecting the host kernel. This is needed both
for retpoline and for IBRS.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/nospec-branch.h | 72 ++++++++++++++++++++++++++++++++++++
arch/x86/kvm/svm.c | 4 ++
arch/x86/kvm/vmx.c | 4 ++
3 files changed, 80 insertions(+)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 7d70ea9..8fbc8b9 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -7,6 +7,50 @@
#include <asm/alternative-asm.h>
#include <asm/cpufeatures.h>
+/*
+ * Fill the CPU return stack buffer.
+ *
+ * Each entry in the RSB, if used for a speculative 'ret', contains an
+ * infinite 'pause; jmp' loop to capture speculative execution.
+ *
+ * This is required in various cases for retpoline and IBRS-based
+ * mitigations for the Spectre variant 2 vulnerability. Sometimes to
+ * eliminate potentially bogus entries from the RSB, and sometimes
+ * purely to ensure that it doesn't get empty, which on some CPUs would
+ * allow predictions from other (unwanted!) sources to be used.
+ *
+ * We define a CPP macro such that it can be used from both .S files and
+ * inline assembly. It's possible to do a .macro and then include that
+ * from C via asm(".include <asm/nospec-branch.h>") but let's not go there=
next prev parent reply other threads:[~2018-01-11 9:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 22:51 [PATCH] x86/retpoline: Fill return stack buffer on vmexit David Woodhouse
2018-01-10 23:22 ` David Lang
2018-01-10 23:32 ` Woodhouse, David
2018-01-10 23:47 ` Tim Chen
2018-01-11 0:04 ` Woodhouse, David
2018-01-11 8:42 ` Peter Zijlstra
2018-01-11 8:49 ` Boris Petkov
2018-01-11 9:07 ` Woodhouse, David [this message]
2018-01-11 9:32 ` Peter Zijlstra
2018-01-11 9:47 ` Borislav Petkov
2018-01-11 9:58 ` Peter Zijlstra
2018-01-11 9:58 ` Woodhouse, David
2018-01-10 23:47 ` David Woodhouse
2018-01-11 0:14 ` Tom Lendacky
2018-01-11 1:04 ` David Woodhouse
2018-01-11 1:12 ` David Woodhouse
2018-01-12 0:34 ` Tom Lendacky
2018-01-11 8:49 ` Peter Zijlstra
2018-01-11 12:10 ` 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=1515661628.22302.294.camel@amazon.co.uk \
--to=dwmw@amazon.co.uk \
--cc=Thomas.Lendacky@amd.com \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--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=pjt@google.com \
--cc=rga@amazon.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.