As described in the comment, some noinstr functions really need to make
indirect calls.
Those functions could be rewritten to use static calls, but that just
shifts the "assume it's instrumented" to "assume the indirect call is
fine" which seems like just moving the problem around.
Instead here's a way to selectively mark functions that are known to be
in the danger zone, and we'll just have to be careful with them.
Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
---
tools/objtool/check.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 0a33d9195b7a9..a760a858d8aa3 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3425,6 +3425,17 @@ static bool pv_call_dest(struct objtool_file *file, struct instruction *insn)
return file->pv_ops[idx].clean;
}
+static inline bool allow_noinstr_indirect_call(struct symbol *func)
+{
+ /*
+ * These functions are noinstr but make indirect calls. The programmer
+ * solemnly promises that the target functions are noinstr too, but they
+ * might be in modules so we can't prove it here.
+ */
+ return (!strcmp(func->name, "asi_exit") ||
+ !strcmp(func->name, "__asi_enter"));
+}
+
static inline bool noinstr_call_dest(struct objtool_file *file,
struct instruction *insn,
struct symbol *func)
@@ -3437,6 +3448,9 @@ static inline bool noinstr_call_dest(struct objtool_file *file,
if (file->pv_ops)
return pv_call_dest(file, insn);
+ if (allow_noinstr_indirect_call(insn->sym))
+ return true;
+
return false;
}
--
2.45.2.993.g49e7a77208-goog
