From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool: Fix SLS checks
Date: Mon, 2 May 2022 22:17:39 +0200 [thread overview]
Message-ID: <YnA8Yw19AQV28w54@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20220502181547.fzz2yre2p4akph4s@treble>
On Mon, May 02, 2022 at 11:15:47AM -0700, Josh Poimboeuf wrote:
> 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) {
Yes, agreed. But perhaps with something like this on top?
---
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index 3c66073e7645..84beeb5297d5 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -452,6 +452,17 @@ static int patch_retpoline(void *addr, struct insn *insn, u8 *bytes)
return ret;
i += ret;
+#ifdef CONFIG_SLS
+ /*
+ * Ideally this would be unconditional, except in case of
+ * RETPOLINE_LFENCE we don't have sufficient space. Additionally,
+ * -mharden-sls=all should be extended to emit INT3 after
+ * direct jumps too, which will then cover that case.
+ */
+ if (i < insn->length)
+ bytes[i++] = INT3_INSN_OPCODE;
+#endif
+
for (; i < insn->length;)
bytes[i++] = BYTES_NOP1;
diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S
index b2b2366885a2..26e742da3129 100644
--- a/arch/x86/lib/retpoline.S
+++ b/arch/x86/lib/retpoline.S
@@ -33,9 +33,9 @@ SYM_INNER_LABEL(__x86_indirect_thunk_\reg, SYM_L_GLOBAL)
UNWIND_HINT_EMPTY
ANNOTATE_NOENDBR
- ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), \
+ ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; INDIRECT_JMP \reg), \
__stringify(RETPOLINE \reg), X86_FEATURE_RETPOLINE, \
- __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg; int3), X86_FEATURE_RETPOLINE_LFENCE
+ __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; INDIRECT_JMP \reg), X86_FEATURE_RETPOLINE_LFENCE
.endm
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 16b6efacf7c6..6929856e7f6d 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -418,6 +418,10 @@ static void emit_indirect_jump(u8 **pprog, int reg, u8 *ip)
#endif
EMIT2(0xFF, 0xE0 + reg);
+#ifdef CONFIG_SLS
+ EMIT1(0xCC);
+#endif
+
*pprog = prog;
}
next prev parent reply other threads:[~2022-05-02 20:17 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
2022-05-02 20:01 ` Peter Zijlstra
2022-05-02 20:09 ` Josh Poimboeuf
2022-05-02 20:17 ` Peter Zijlstra [this message]
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=YnA8Yw19AQV28w54@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.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
all inboxes | Powered by JetHome®