From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: x86@kernel.org, andrew.cooper3@citrix.com,
linux-kernel@vger.kernel.org, alexei.starovoitov@gmail.com,
ndesaulniers@google.com
Subject: Re: [PATCH 4/9] x86/alternative: Implement .retpoline_sites support
Date: Tue, 19 Oct 2021 13:37:09 +0200 [thread overview]
Message-ID: <YW6t5catO1mx+eCZ@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20211013205259.44cvvaxiexiff5w5@treble>
On Wed, Oct 13, 2021 at 01:52:59PM -0700, Josh Poimboeuf wrote:
> BTW, CALL_NOSPEC results in a retpoline site in .altinstr_replacement:
>
> Relocation section [40] '.rela.retpoline_sites' for section [39] '.retpoline_sites' at offset 0x8d28 contains 1 entry:
> Offset Type Value Addend Name
> 000000000000000000 X86_64_PC32 000000000000000000 +10 .altinstr_replacement
>
> Which I assume we don't want.
(I missed this initially, and just independently rediscovered it)
In principle this problem affects static_call_list, the __sanitizer_cov_
and __fentry__ and now retpoline_sites.
Granted, it seems really unlikely to find __fentry__ or __sanitizer_cov_
references in alternatives, but it should be trivial to manually create
one.
I'm thinking we want to exclude all those when found in
.altinstr_replacement, right? It just doesn't make sense to rewrite
replacement text.
How is something like the below? (I'm not completely happy with it, but
I couldn't think of something better either).
---
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1039,14 +1039,39 @@ static void remove_insn_ops(struct instr
}
}
+#define DEST_RETPOLINE ((void *)-1L)
+
static void add_call_dest(struct objtool_file *file, struct instruction *insn,
struct symbol *dest, bool sibling)
{
struct reloc *reloc = insn_reloc(file, insn);
- insn->call_dest = dest;
- if (!dest)
+ if (dest != DEST_RETPOLINE) {
+ insn->call_dest = dest;
+ if (!dest )
+ return;
+ }
+
+ /*
+ * Whatever stack impact regular CALLs have, should be undone
+ * by the RETURN of the called function.
+ *
+ * Annotated intra-function calls retain the stack_ops but
+ * are converted to JUMP, see read_intra_function_calls().
+ */
+ remove_insn_ops(insn);
+
+ /*
+ * Whatever we do, do not rewrite replacement text.
+ */
+ if (!strcmp(insn->sec->name, ".altinstr_replacement"))
+ return;
+
+ if (dest == DEST_RETPOLINE) {
+ list_add_tail(&insn->call_node,
+ &file->retpoline_call_list);
return;
+ }
if (insn->call_dest->static_call_tramp) {
list_add_tail(&insn->call_node,
@@ -1091,15 +1116,6 @@ static void add_call_dest(struct objtool
list_add_tail(&insn->mcount_loc_node,
&file->mcount_loc_list);
}
-
- /*
- * Whatever stack impact regular CALLs have, should be undone
- * by the RETURN of the called function.
- *
- * Annotated intra-function calls retain the stack_ops but
- * are converted to JUMP, see read_intra_function_calls().
- */
- remove_insn_ops(insn);
}
/*
@@ -1133,10 +1149,9 @@ static int add_jump_destinations(struct
else
insn->type = INSN_JUMP_DYNAMIC_CONDITIONAL;
- list_add_tail(&insn->call_node,
- &file->retpoline_call_list);
-
insn->retpoline_safe = true;
+
+ add_call_dest(file, insn, DEST_RETPOLINE, true);
continue;
} else if (insn->func) {
/* internal or external sibling call (with reloc) */
@@ -1272,12 +1287,7 @@ static int add_call_destinations(struct
insn->type = INSN_CALL_DYNAMIC;
insn->retpoline_safe = true;
- list_add_tail(&insn->call_node,
- &file->retpoline_call_list);
-
- remove_insn_ops(insn);
- continue;
-
+ add_call_dest(file, insn, DEST_RETPOLINE, false);
} else
add_call_dest(file, insn, reloc->sym, false);
}
next prev parent reply other threads:[~2021-10-19 11:37 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 12:22 [PATCH 0/9] x86: Rewrite the retpoline rewrite logic Peter Zijlstra
2021-10-13 12:22 ` [PATCH 1/9] objtool,x86: Replace alternatives with .retpoline_sites Peter Zijlstra
2021-10-13 13:29 ` Borislav Petkov
2021-10-13 20:11 ` Josh Poimboeuf
2021-10-14 15:43 ` Peter Zijlstra
2021-10-13 12:22 ` [PATCH 2/9] x86/retpoline: Remove unused replacement symbols Peter Zijlstra
2021-10-13 12:22 ` [PATCH 3/9] x86/asm: Fix register order Peter Zijlstra
2021-10-13 20:15 ` Josh Poimboeuf
2021-10-13 12:22 ` [PATCH 4/9] x86/alternative: Implement .retpoline_sites support Peter Zijlstra
2021-10-13 14:38 ` Andrew Cooper
2021-10-13 15:12 ` Peter Zijlstra
2021-10-13 17:11 ` Andrew Cooper
2021-10-14 10:05 ` Peter Zijlstra
2021-10-13 20:39 ` Josh Poimboeuf
2021-10-13 21:20 ` Peter Zijlstra
2021-10-13 21:49 ` Josh Poimboeuf
2021-10-13 21:52 ` Josh Poimboeuf
2021-10-13 22:10 ` Peter Zijlstra
2021-10-13 22:47 ` Andrew Cooper
2021-10-13 20:52 ` Josh Poimboeuf
2021-10-13 21:00 ` Peter Zijlstra
2021-10-19 11:37 ` Peter Zijlstra [this message]
2021-10-19 16:46 ` Josh Poimboeuf
2021-10-19 16:49 ` Josh Poimboeuf
2021-10-20 8:25 ` Peter Zijlstra
2021-10-20 8:30 ` Peter Zijlstra
2021-10-13 21:11 ` Josh Poimboeuf
2021-10-13 21:43 ` Peter Zijlstra
2021-10-13 22:05 ` Josh Poimboeuf
2021-10-13 22:14 ` Peter Zijlstra
2021-10-15 14:24 ` Borislav Petkov
2021-10-15 16:56 ` Peter Zijlstra
2021-10-18 23:06 ` Alexander Lobakin
2021-10-19 0:25 ` Alexander Lobakin
2021-10-19 9:47 ` Alexander Lobakin
2021-10-19 10:16 ` Peter Zijlstra
2021-10-19 15:37 ` Sami Tolvanen
2021-10-19 18:00 ` Alexander Lobakin
2021-10-19 9:40 ` Peter Zijlstra
2021-10-19 10:02 ` Peter Zijlstra
2021-10-13 12:22 ` [PATCH 5/9] x86/alternative: Handle Jcc __x86_indirect_thunk_\reg Peter Zijlstra
2021-10-13 20:11 ` Nick Desaulniers
2021-10-13 21:08 ` Peter Zijlstra
2021-10-13 12:22 ` [PATCH 6/9] x86/alternative: Try inline spectre_v2=retpoline,amd Peter Zijlstra
2021-10-13 12:22 ` [PATCH 7/9] x86/alternative: Add debug prints to apply_retpolines() Peter Zijlstra
2021-10-13 12:22 ` [PATCH 8/9] x86,bugs: Unconditionally allow spectre_v2=retpoline,amd Peter Zijlstra
2021-10-13 12:22 ` [PATCH 9/9] bpf,x86: Respect X86_FEATURE_RETPOLINE* Peter Zijlstra
2021-10-13 21:06 ` Josh Poimboeuf
2021-10-13 21:54 ` Peter Zijlstra
2021-10-14 9:46 ` Peter Zijlstra
2021-10-14 9:48 ` Peter Zijlstra
2021-10-20 7:34 ` 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=YW6t5catO1mx+eCZ@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrew.cooper3@citrix.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ndesaulniers@google.com \
--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