mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool: Fix SLS checks
Date: Mon, 2 May 2022 11:15:47 -0700	[thread overview]
Message-ID: <20220502181547.fzz2yre2p4akph4s@treble> (raw)
In-Reply-To: <Ym0UWja2L40QbgEc@hirez.programming.kicks-ass.net>

On Sat, Apr 30, 2022 at 12:50:02PM +0200, Peter Zijlstra wrote:
> 
> Fix the SLS validation; not having a next instruction is also a fail
> when the next instruction should be INSN_TRAP.
> 
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  tools/objtool/check.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 3f6785415894..3354101ffe34 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -3380,7 +3380,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  
>  		case INSN_RETURN:
>  			if (sls && !insn->retpoline_safe &&
> -			    next_insn && next_insn->type != INSN_TRAP) {
> +			    (!next_insn || (next_insn && next_insn->type != INSN_TRAP))) {
>  				WARN_FUNC("missing int3 after ret",
>  					  insn->sec, insn->offset);
>  			}
> @@ -3428,7 +3428,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  
>  		case INSN_JUMP_DYNAMIC:
>  			if (sls && !insn->retpoline_safe &&
> -			    next_insn && next_insn->type != INSN_TRAP) {
> +			    (!next_insn || (next_insn && next_insn->type != INSN_TRAP))) {
>  				WARN_FUNC("missing int3 after indirect jump",
>  					  insn->sec, insn->offset);
>  			}

My SLS rewrite in tip/objtool/core already fixed this, FWIW.  But this
could be good for -urgent.

Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>

Here's another SLS improvement I mentioned to you the other day, do you
agree we should do this as well?


From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] x86/speculation: Mitigate SLS for JMP_NOSPEC with retpolines disabled

Having disabled retpolines doesn't necessarily mean the user doesn't
care about straight-line speculation.  For example, retpolines are
disabled when eIBRS is used.

If CONFIG_SLS is enabled, properly mitigate SLS for JMP_NOSPEC for the
retpolines disabled cases.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 arch/x86/include/asm/nospec-branch.h | 13 ++++++++++---
 tools/objtool/check.c                |  3 ---
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index acbaeaf83b61..0648746bf60b 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -75,6 +75,13 @@
 	.popsection
 .endm
 
+.macro INDIRECT_JMP reg
+	jmp *%\reg
+#ifdef CONFIG_SLS
+	int3
+#endif
+.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
@@ -82,11 +89,11 @@
  */
 .macro JMP_NOSPEC reg:req
 #ifdef CONFIG_RETPOLINE
-	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), \
+	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; INDIRECT_JMP \reg), \
 		      __stringify(jmp __x86_indirect_thunk_\reg), X86_FEATURE_RETPOLINE, \
-		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), X86_FEATURE_RETPOLINE_LFENCE
+		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; INDIRECT_JMP \reg), X86_FEATURE_RETPOLINE_LFENCE
 #else
-	jmp	*%\reg
+	INDIRECT_JMP \reg
 #endif
 .endm
 
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index e7983c3e2408..3cf3ad0b5db5 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3842,9 +3842,6 @@ static int validate_sls(struct objtool_file *file)
 	for_each_insn(file, insn) {
 		next_insn = next_insn_same_sec(file, insn);
 
-		if (insn->retpoline_safe)
-			continue;
-
 		switch (insn->type) {
 		case INSN_RETURN:
 			if (!next_insn || next_insn->type != INSN_TRAP) {
-- 
2.34.1


  reply	other threads:[~2022-05-02 18:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-30 10:50 Peter Zijlstra
2022-05-02 18:15 ` Josh Poimboeuf [this message]
2022-05-02 20:01   ` Peter Zijlstra
2022-05-02 20:09     ` Josh Poimboeuf
2022-05-02 20:17   ` Peter Zijlstra
2022-05-03 21:15     ` Josh Poimboeuf
2022-05-04  7:26       ` Peter Zijlstra
2022-05-05 21:03         ` Josh Poimboeuf

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=20220502181547.fzz2yre2p4akph4s@treble \
    --to=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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®