On Wed, Aug 16, 2023 at 07:55:17AM -0000, tip-bot2 for Peter Zijlstra wrote:
> The following commit has been merged into the x86/urgent branch of tip:
>
> Commit-ID: 4ae68b26c3ab5a82aa271e6e9fc9b1a06e1d6b40
> Gitweb: https://git.kernel.org/tip/4ae68b26c3ab5a82aa271e6e9fc9b1a06e1d6b40
> Author: Peter Zijlstra <[email protected]>
> AuthorDate: Mon, 14 Aug 2023 13:44:29 +02:00
> Committer: Borislav Petkov (AMD) <[email protected]>
> CommitterDate: Wed, 16 Aug 2023 09:39:16 +02:00
>
> objtool/x86: Fix SRSO mess
>
> Objtool --rethunk does two things:
>
> - it collects all (tail) call's of __x86_return_thunk and places them
> into .return_sites. These are typically compiler generated, but
> RET also emits this same.
>
> - it fudges the validation of the __x86_return_thunk symbol; because
> this symbol is inside another instruction, it can't actually find
> the instruction pointed to by the symbol offset and gets upset.
>
> Because these two things pertained to the same symbol, there was no
> pressing need to separate these two separate things.
>
> However, alas, along comes SRSO and more crazy things to deal with
> appeared.
>
> The SRSO patch itself added the following symbol names to identify as
> rethunk:
>
> 'srso_untrain_ret', 'srso_safe_ret' and '__ret'
>
> Where '__ret' is the old retbleed return thunk, 'srso_safe_ret' is a
> new similarly embedded return thunk, and 'srso_untrain_ret' is
> completely unrelated to anything the above does (and was only included
> because of that INT3 vs UD2 issue fixed previous).
>
> Clear things up by adding a second category for the embedded instruction
> thing.
>
> Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> Signed-off-by: Borislav Petkov (AMD) <[email protected]>
> Link: https://lore.kernel.org/r/[email protected]
Turns out I forgot to build with FRAME_POINTER=y, that still gives:
vmlinux.o: warning: objtool: srso_untrain_ret+0xd: call without frame pointer save/setup
the below seems to cure this.
---
tools/objtool/check.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 7a9aaf400873..1384090530db 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2650,12 +2650,17 @@ static int decode_sections(struct objtool_file *file)
return 0;
}
-static bool is_fentry_call(struct instruction *insn)
+static bool is_special_call(struct instruction *insn)
{
- if (insn->type == INSN_CALL &&
- insn_call_dest(insn) &&
- insn_call_dest(insn)->fentry)
- return true;
+ if (insn->type == INSN_CALL) {
+ struct symbol *dest = insn_call_dest(insn);
+
+ if (!dest)
+ return false;
+
+ if (dest->fentry || dest->embedded_insn)
+ return true;
+ }
return false;
}
@@ -3656,7 +3661,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
if (ret)
return ret;
- if (opts.stackval && func && !is_fentry_call(insn) &&
+ if (opts.stackval && func && !is_special_call(insn) &&
!has_valid_stack_frame(&state)) {
WARN_INSN(insn, "call without frame pointer save/setup");
return 1;
On Wed, Aug 16, 2023 at 01:59:21PM +0200, Peter Zijlstra wrote:
> Turns out I forgot to build with FRAME_POINTER=y, that still gives:
>
> vmlinux.o: warning: objtool: srso_untrain_ret+0xd: call without frame pointer save/setup
>
> the below seems to cure this.
LGTM
--
Josh