[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <169780183488.3135.1271262066935601198.tip-bot2@tip-bot2>
Date: Fri, 20 Oct 2023 11:37:14 -0000
From: "tip-bot2 for Josh Poimboeuf" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: David Kaplan <david.kaplan@....com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
"Borislav Petkov (AMD)" <bp@...en8.de>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: [tip: x86/bugs] objtool: Fix return thunk patching in retpolines
The following commit has been merged into the x86/bugs branch of tip:
Commit-ID: 34de4fe7d1326c5c27890df3297dffd4c7196b0e
Gitweb: https://git.kernel.org/tip/34de4fe7d1326c5c27890df3297dffd4c7196b0e
Author: Josh Poimboeuf <jpoimboe@...nel.org>
AuthorDate: Wed, 11 Oct 2023 19:47:37 -07:00
Committer: Borislav Petkov (AMD) <bp@...en8.de>
CommitterDate: Fri, 20 Oct 2023 12:51:41 +02:00
objtool: Fix return thunk patching in retpolines
With CONFIG_RETHUNK enabled, the compiler replaces every RET with a tail
call to a return thunk ('JMP __x86_return_thunk'). Objtool annotates
all such return sites so they can be patched during boot by
apply_returns().
The implementation of __x86_return_thunk() is just a bare RET. It's
only meant to be used temporarily until apply_returns() patches all
return sites with either a JMP to another return thunk or an actual RET.
Removing the .text..__x86.return_thunk section would break objtool's
detection of return sites in retpolines. Since retpolines and return
thunks would land in the same section, the compiler no longer uses
relocations for the intra-section jumps between the retpolines and the
return thunk, causing objtool to overlook them.
As a result, none of the retpolines' return sites would get patched.
Each one stays at 'JMP __x86_return_thunk', effectively a bare RET.
Fix it by teaching objtool to detect when a non-relocated jump target is
a return thunk (or retpoline).
[ bp: Massage the commit message now that the offending commit
removing the .text..__x86.return_thunk section has been zapped.
Still keep the objtool change here as it makes objtool more robust
wrt handling such intra-TU jumps without relocations, should some
toolchain and/or config generate them in the future. ]
Reported-by: David Kaplan <david.kaplan@....com>
Signed-off-by: Josh Poimboeuf <jpoimboe@...nel.org>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Link: https://lore.kernel.org/r/20231012024737.eg5phclogp67ik6x@treble
---
tools/objtool/check.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index e308d1b..e94756e 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1611,6 +1611,22 @@ static int add_jump_destinations(struct objtool_file *file)
}
/*
+ * An intra-TU jump in retpoline.o might not have a relocation
+ * for its jump dest, in which case the above
+ * add_{retpoline,return}_call() didn't happen.
+ */
+ if (jump_dest->sym && jump_dest->offset == jump_dest->sym->offset) {
+ if (jump_dest->sym->retpoline_thunk) {
+ add_retpoline_call(file, insn);
+ continue;
+ }
+ if (jump_dest->sym->return_thunk) {
+ add_return_call(file, insn, true);
+ continue;
+ }
+ }
+
+ /*
* Cross-function jump.
*/
if (insn_func(insn) && insn_func(jump_dest) &&
Powered by blists - more mailing lists