All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tip-bot2 for Peter Zijlstra" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Jann Horn <jannh@google.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Miroslav Benes <mbenes@suse.cz>,
	Josh Poimboeuf <jpoimboe@redhat.com>, x86 <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: [tip: objtool/core] objtool: Fix ORC vs alternatives
Date: Fri, 01 May 2020 18:22:23 -0000	[thread overview]
Message-ID: <158835734305.8414.7228235752870624259.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20200428191659.499074346@infradead.org>

The following commit has been merged into the objtool/core branch of tip:

Commit-ID:     7117f16bf460ef8cd132e6e80c989677397b4868
Gitweb:        https://git.kernel.org/tip/7117f16bf460ef8cd132e6e80c989677397b4868
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Tue, 28 Apr 2020 19:37:01 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Thu, 30 Apr 2020 20:14:31 +02:00

objtool: Fix ORC vs alternatives

Jann reported that (for instance) entry_64.o:general_protection has
very odd ORC data:

  0000000000000f40 <general_protection>:
  #######sp:sp+8 bp:(und) type:iret end:0
    f40:       90                      nop
  #######sp:(und) bp:(und) type:call end:0
    f41:       90                      nop
    f42:       90                      nop
  #######sp:sp+8 bp:(und) type:iret end:0
    f43:       e8 a8 01 00 00          callq  10f0 <error_entry>
  #######sp:sp+0 bp:(und) type:regs end:0
    f48:       f6 84 24 88 00 00 00    testb  $0x3,0x88(%rsp)
    f4f:       03
    f50:       74 00                   je     f52 <general_protection+0x12>
    f52:       48 89 e7                mov    %rsp,%rdi
    f55:       48 8b 74 24 78          mov    0x78(%rsp),%rsi
    f5a:       48 c7 44 24 78 ff ff    movq   $0xffffffffffffffff,0x78(%rsp)
    f61:       ff ff
    f63:       e8 00 00 00 00          callq  f68 <general_protection+0x28>
    f68:       e9 73 02 00 00          jmpq   11e0 <error_exit>
  #######sp:(und) bp:(und) type:call end:0
    f6d:       0f 1f 00                nopl   (%rax)

Note the entry at 0xf41. Josh found this was the result of commit:

  764eef4b109a ("objtool: Rewrite alt->skip_orig")

Due to the early return in validate_branch() we no longer set
insn->cfi of the original instruction stream (the NOPs at 0xf41 and
0xf42) and we'll end up with the above weirdness.

In other discussions we realized alternatives should be ORC invariant;
that is, due to there being only a single ORC table, it must be valid
for all alternatives. The easiest way to ensure this is to not allow
any stack modifications in alternatives.

When we enforce this latter observation, we get the property that the
whole alternative must have the same CFI, which we can employ to fix
the former report.

Fixes: 764eef4b109a ("objtool: Rewrite alt->skip_orig")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20200428191659.499074346@infradead.org
---
 tools/objtool/Documentation/stack-validation.txt |  7 +++-
 tools/objtool/check.c                            | 34 ++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/Documentation/stack-validation.txt b/tools/objtool/Documentation/stack-validation.txt
index faa47c3..0189039 100644
--- a/tools/objtool/Documentation/stack-validation.txt
+++ b/tools/objtool/Documentation/stack-validation.txt
@@ -315,6 +315,13 @@ they mean, and suggestions for how to fix them.
       function tracing inserts additional calls, which is not obvious from the
       sources).
 
+10. file.o: warning: func()+0x5c: alternative modifies stack
+
+    This means that an alternative includes instructions that modify the
+    stack. The problem is that there is only one ORC unwind table, this means
+    that the ORC unwind entries must be valid for each of the alternatives.
+    The easiest way to enforce this is to ensure alternatives do not contain
+    any ORC entries, which in turn implies the above constraint.
 
 If the error doesn't seem to make sense, it could be a bug in objtool.
 Feel free to ask the objtool maintainer for help.
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 4da6bfb..fa9bf36 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1983,6 +1983,11 @@ static int handle_insn_ops(struct instruction *insn, struct insn_state *state)
 	list_for_each_entry(op, &insn->stack_ops, list) {
 		int res;
 
+		if (insn->alt_group) {
+			WARN_FUNC("alternative modifies stack", insn->sec, insn->offset);
+			return -1;
+		}
+
 		res = update_cfi_state(insn, &state->cfi, op);
 		if (res)
 			return res;
@@ -2150,6 +2155,30 @@ static int validate_return(struct symbol *func, struct instruction *insn, struct
 }
 
 /*
+ * Alternatives should not contain any ORC entries, this in turn means they
+ * should not contain any CFI ops, which implies all instructions should have
+ * the same same CFI state.
+ *
+ * It is possible to constuct alternatives that have unreachable holes that go
+ * unreported (because they're NOPs), such holes would result in CFI_UNDEFINED
+ * states which then results in ORC entries, which we just said we didn't want.
+ *
+ * Avoid them by copying the CFI entry of the first instruction into the whole
+ * alternative.
+ */
+static void fill_alternative_cfi(struct objtool_file *file, struct instruction *insn)
+{
+	struct instruction *first_insn = insn;
+	int alt_group = insn->alt_group;
+
+	sec_for_each_insn_continue(file, insn) {
+		if (insn->alt_group != alt_group)
+			break;
+		insn->cfi = first_insn->cfi;
+	}
+}
+
+/*
  * Follow the branch starting at the given instruction, and recursively follow
  * any other branches (jumps).  Meanwhile, track the frame pointer state at
  * each instruction and validate all the rules described in
@@ -2200,7 +2229,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 
 		insn->visited |= visited;
 
-		if (!insn->ignore_alts) {
+		if (!insn->ignore_alts && !list_empty(&insn->alts)) {
 			bool skip_orig = false;
 
 			list_for_each_entry(alt, &insn->alts, list) {
@@ -2215,6 +2244,9 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 				}
 			}
 
+			if (insn->alt_group)
+				fill_alternative_cfi(file, insn);
+
 			if (skip_orig)
 				return 0;
 		}

  parent reply	other threads:[~2020-05-01 18:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 19:11 [PATCH v2 00/14] objtool vs retpoline Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 01/14] objtool: Allow branches within the same alternative Peter Zijlstra
2020-04-28 19:53   ` Josh Poimboeuf
2020-04-28 19:11 ` [PATCH v2 02/14] objtool: Fix ORC vs alternatives Peter Zijlstra
2020-04-28 19:55   ` Josh Poimboeuf
2020-04-29 14:33   ` Miroslav Benes
2020-04-29 15:51     ` Peter Zijlstra
2020-04-29 16:41       ` Miroslav Benes
2020-05-01 18:22   ` tip-bot2 for Peter Zijlstra [this message]
2020-04-28 19:11 ` [PATCH v2 03/14] x86,smap: Fix smap_{save,restore}() alternatives Peter Zijlstra
2020-04-29  0:54   ` Brian Gerst
2020-04-29  8:30     ` Peter Zijlstra
2020-04-29 10:18       ` Peter Zijlstra
2020-04-29 12:12         ` Brian Gerst
2020-05-01 18:22         ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 04/14] objtool: is_fentry_call() crashes if call has no destination Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 05/14] objtool: UNWIND_HINT_RET_OFFSET should not check registers Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 06/14] objtool: Rework allocating stack_ops on decode Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 07/14] objtool: Make handle_insn_ops() unconditional Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-05-07 12:38     ` Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 08/14] objtool: Remove INSN_STACK Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 09/14] objtool: Move the IRET hack into the arch decoder Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Miroslav Benes
2020-04-28 19:11 ` [PATCH v2 10/14] objtool: Add support for intra-function calls Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 11/14] x86/speculation: Change FILL_RETURN_BUFFER to work with objtool Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 12/14] x86: Simplify retpoline declaration Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 13/14] x86: Change {JMP,CALL}_NOSPEC argument Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 19:11 ` [PATCH v2 14/14] x86/retpoline: Fix retpoline unwind Peter Zijlstra
2020-05-01 18:22   ` [tip: objtool/core] " tip-bot2 for Peter Zijlstra
2020-04-28 20:17 ` [PATCH v2 00/14] objtool vs retpoline Josh Poimboeuf
2020-04-29 10:19 ` [PATCH v2.1 01-A/14] objtool: Remove check preventing branches within alternative Peter Zijlstra
2020-04-29 10:21 ` [PATCH v2.1 01-B/14] objtool: Uniquely identify alternative instruction groups Peter Zijlstra
2020-04-29 16:46 ` [PATCH v2 00/14] objtool vs retpoline Miroslav Benes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=158835734305.8414.7228235752870624259.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=jannh@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.