[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240925150059.3955569-54-ardb+git@google.com>
Date: Wed, 25 Sep 2024 17:01:24 +0200
From: Ard Biesheuvel <ardb+git@...gle.com>
To: linux-kernel@...r.kernel.org
Cc: Ard Biesheuvel <ardb@...nel.org>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Uros Bizjak <ubizjak@...il.com>,
Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Paolo Bonzini <pbonzini@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>, Juergen Gross <jgross@...e.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arnd Bergmann <arnd@...db.de>,
Masahiro Yamada <masahiroy@...nel.org>, Kees Cook <kees@...nel.org>,
Nathan Chancellor <nathan@...nel.org>, Keith Packard <keithp@...thp.com>,
Justin Stitt <justinstitt@...gle.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>, linux-doc@...r.kernel.org,
linux-pm@...r.kernel.org, kvm@...r.kernel.org, xen-devel@...ts.xenproject.org,
linux-efi@...r.kernel.org, linux-arch@...r.kernel.org,
linux-sparse@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-perf-users@...r.kernel.org, rust-for-linux@...r.kernel.org,
llvm@...ts.linux.dev
Subject: [RFC PATCH 24/28] tools/objtool: Treat indirect ftrace calls as
direct calls
From: Ard Biesheuvel <ardb@...nel.org>
In some cases, the compiler may rely on indirect calls using GOT slots
as memory operands to emit function calls. This leaves it up to the
linker to relax the call to a direct call if possible, i.e., if the
destination address is known at link time and in range, which may not be
the case when building shared libraries for user space.
On x86, this may happen when building in PIC mode with ftrace enabled,
and given that vmlinux is a fully linked binary, this relaxation is
always possible, and therefore mandatory per the x86_64 psABI.
This means that the indirect calls to __fentry__ that are observeable in
vmlinux.o will have been converted to direct calls in vmlinux, and can
be treated as such by objtool.
Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
---
tools/objtool/check.c | 32 ++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 04725bd83232..94a56099e22d 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1696,11 +1696,39 @@ static int add_call_destinations(struct objtool_file *file)
struct reloc *reloc;
for_each_insn(file, insn) {
- if (insn->type != INSN_CALL)
+ if (insn->type != INSN_CALL &&
+ insn->type != INSN_CALL_DYNAMIC)
continue;
reloc = insn_reloc(file, insn);
- if (!reloc) {
+ if (insn->type == INSN_CALL_DYNAMIC) {
+ if (!reloc)
+ continue;
+
+ /*
+ * GCC 13 and older on x86 will always emit the call to
+ * __fentry__ using a relaxable GOT-based symbol
+ * reference when operating in PIC mode, i.e.,
+ *
+ * call *0x0(%rip)
+ * R_X86_64_GOTPCRELX __fentry__-0x4
+ *
+ * where it is left up to the linker to relax this into
+ *
+ * call __fentry__
+ * nop
+ *
+ * if __fentry__ turns out to be DSO local, which is
+ * always the case for vmlinux. Given that this
+ * relaxation is mandatory per the x86_64 psABI, these
+ * calls can simply be treated as direct calls.
+ */
+ if (arch_ftrace_match(reloc->sym->name)) {
+ insn->type = INSN_CALL;
+ add_call_dest(file, insn, reloc->sym, false);
+ }
+
+ } else if (!reloc) {
dest_off = arch_jump_destination(insn);
dest = find_call_destination(insn->sec, dest_off);
--
2.46.0.792.g87dc391469-goog
Powered by blists - more mailing lists