linux-kernel - Re: [tip: x86/urgent] objtool/x86: Fix SRSO mess

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230816115921.GH980931@hirez.programming.kicks-ass.net>
Date:   Wed, 16 Aug 2023 13:59:21 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     linux-kernel@...r.kernel.org
Cc:     linux-tip-commits@...r.kernel.org,
        "Borislav Petkov (AMD)" <bp@...en8.de>, x86@...nel.org
Subject: Re: [tip: x86/urgent] objtool/x86: Fix SRSO mess

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 <peterz@...radead.org>
> AuthorDate:    Mon, 14 Aug 2023 13:44:29 +02:00
> Committer:     Borislav Petkov (AMD) <bp@...en8.de>
> 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) <peterz@...radead.org>
> Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
> Link: https://lore.kernel.org/r/20230814121148.704502245@infradead.org

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;