linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: linux-kernel@vger.kernel.org, keescook@chromium.org,
	hjl.tools@gmail.com, andrew.cooper3@citrix.com,
	mark.rutland@arm.com, will@kernel.org, ndesaulniers@google.com,
	x86@kernel.org, Ankur Arora <ankur.a.arora@oracle.com>
Subject: [RFC][PATCH] x86,nospec: Simplify {JMP,CALL}_NOSPEC
Date: Tue, 19 Jul 2022 23:23:06 +0200	[thread overview]
Message-ID: <Ytcguqp+/aTiOcnN@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <9011132e-d78b-8bec-10cb-2b3d77a4e1fc@maciej.szmigiero.name>

On Tue, Jul 19, 2022 at 03:19:26PM +0200, Maciej S. Szmigiero wrote:
> On 4.12.2021 14:43, Peter Zijlstra wrote:
> > Make use of an upcomming GCC feature to mitigate
> > straight-line-speculation for x86:
> > 
> >    https://gcc.gnu.org/g:53a643f8568067d7700a9f2facc8ba39974973d3
> >    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
> >    https://bugs.llvm.org/show_bug.cgi?id=52323
> > 
> > It's built tested on x86_64-allyesconfig using GCC-12 and GCC-11.
> > 
> > Maintenace overhead of this should be fairly low due to objtool
> > validation.
> > 
> > Size overhead of all these additional int3 instructions comes to:
> > 
> >     text	   data	    bss	    dec	    hex	filename
> > 22267751	6933356	2011368	31212475	1dc43bb	defconfig-build/vmlinux
> > 22804126	6933356	1470696	31208178	1dc32f2	defconfig-build/vmlinux.sls
> > 
> > Or roughly 2.4% additional text.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > ---
> (..)
> > --- a/arch/x86/lib/retpoline.S
> > +++ b/arch/x86/lib/retpoline.S
> > @@ -34,7 +34,7 @@ SYM_INNER_LABEL(__x86_indirect_thunk_\re
> >   	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), \
> >   		      __stringify(RETPOLINE \reg), X86_FEATURE_RETPOLINE, \
> > -		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), X86_FEATURE_RETPOLINE_AMD
> > +		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg; int3), X86_FEATURE_RETPOLINE_AMD
> >   .endm
> 
> Looking at this __x86_indirect_thunk_* change makes me wonder why there is
> no similar int3 SLS protection in the X86_FEATURE_RETPOLINE_LFENCE case of
> JMP_NOSPEC in arch/x86/include/asm/nospec-branch.h:
> > .macro JMP_NOSPEC reg:req
> > #ifdef CONFIG_RETPOLINE
> > 	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), \
> > 		      __stringify(jmp __x86_indirect_thunk_\reg), X86_FEATURE_RETPOLINE, \
> > 		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), X86_FEATURE_RETPOLINE_LFENCE
> > #else
> 
> JMP_NOSPEC users seem to have no explicit trailing int3 instructions
> either.
> 
> Or am I missing something here?

Probably just forgot about those. I'm thinking we ought to do something
like this...

---
Subject: x86,nospec: Simplify {JMP,CALL}_NOSPEC

Have {JMP,CALL}_NOSPEC generate the same code GCC does for indirect
calls and rely on the objtool retpoline patching infrastructure.

There's no reason these should be alternatives while the vast bulk of
compiler generated retpolines are not.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 arch/x86/include/asm/nospec-branch.h | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index 10a3bfc1eb23..7bb319d2932c 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -93,6 +93,19 @@
 #endif
 .endm
 
+/*
+ * Equivalent to -mindirect-branch-cs-prefix; emit the 5 byte jmp/call
+ * to the retpoline thunk with a CS prefix when the register requires
+ * a RAX prefix byte to encode. Also see apply_alternatives().
+ */
+.macro __CS_PREFIX reg:req
+	.irp rs,r8,r9,r10,r11,r12,r13,r14,r15
+	.ifc \reg,\rs
+	.byte 0x2e
+	.endif
+	.endr
+.endm
+
 /*
  * JMP_NOSPEC and CALL_NOSPEC macros can be used instead of a simple
  * indirect jmp/call which may be susceptible to the Spectre variant 2
@@ -100,19 +113,18 @@
  */
 .macro JMP_NOSPEC reg:req
 #ifdef CONFIG_RETPOLINE
-	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), \
-		      __stringify(jmp __x86_indirect_thunk_\reg), X86_FEATURE_RETPOLINE, \
-		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), X86_FEATURE_RETPOLINE_LFENCE
+	__CS_PREFIX \reg
+	jmp	__x86_indirect_thunk_\reg
 #else
 	jmp	*%\reg
+	int3
 #endif
 .endm
 
 .macro CALL_NOSPEC reg:req
 #ifdef CONFIG_RETPOLINE
-	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; call *%\reg), \
-		      __stringify(call __x86_indirect_thunk_\reg), X86_FEATURE_RETPOLINE, \
-		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; call *%\reg), X86_FEATURE_RETPOLINE_LFENCE
+	__CS_PREFIX \reg
+	call	__x86_indirect_thunk_\reg
 #else
 	call	*%\reg
 #endif

  reply	other threads:[~2022-07-19 21:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-04 13:43 [PATCH v2 0/6] x86: Add stright-line-speculation mitigations Peter Zijlstra
2021-12-04 13:43 ` [PATCH v2 1/6] x86/atomic64_386_32: Rename things Peter Zijlstra
2021-12-10 11:05   ` [tip: x86/core] x86/lib/atomic64_386_32: " tip-bot2 for Peter Zijlstra
2021-12-04 13:43 ` [PATCH v2 2/6] x86: Prepare asm files for straight-line-speculation Peter Zijlstra
2021-12-10 11:05   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-12-04 13:43 ` [PATCH v2 3/6] x86: Prepare inline-asm " Peter Zijlstra
2021-12-10 11:05   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-12-04 13:43 ` [PATCH v2 4/6] objtool: Add straight-line-speculation validation Peter Zijlstra
2021-12-10 11:05   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-12-04 13:43 ` [PATCH v2 5/6] x86/alternative: Relax text_poke_bp() constraint Peter Zijlstra
2021-12-10 11:05   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-12-04 13:43 ` [PATCH v2 6/6] x86: Add straight-line-speculation mitigation Peter Zijlstra
2021-12-10 11:05   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2022-07-19 13:19   ` Missing SLS int3 in JMP_NOSPEC? (Was: [PATCH v2 6/6] x86: Add straight-line-speculation mitigation) Maciej S. Szmigiero
2022-07-19 21:23     ` Peter Zijlstra [this message]
2022-07-19 21:33       ` [RFC][PATCH] x86,nospec: Simplify {JMP,CALL}_NOSPEC Peter Zijlstra
2022-07-20  0:01         ` Maciej S. Szmigiero
2022-07-20  9:12           ` Peter Zijlstra

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=Ytcguqp+/aTiOcnN@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=ankur.a.arora@oracle.com \
    --cc=hjl.tools@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mail@maciej.szmigiero.name \
    --cc=mark.rutland@arm.com \
    --cc=ndesaulniers@google.com \
    --cc=will@kernel.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).