All of lore.kernel.org
 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 [PATCH] objtool: Fix SLS checks 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 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.