linux-kernel - Re: mmotm 2020-05-05-15-28 uploaded (objtool warning)

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]

Date:   Fri, 8 May 2020 12:38:30 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     akpm@...ux-foundation.org, broonie@...nel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-next@...r.kernel.org, mhocko@...e.cz,
        mm-commits@...r.kernel.org, sfr@...b.auug.org.au,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: mmotm 2020-05-05-15-28 uploaded (objtool warning)

On Tue, May 05, 2020 at 10:40:43PM -0700, Randy Dunlap wrote:
> On 5/5/20 3:29 PM, akpm@...ux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2020-05-05-15-28 has been uploaded to
> > 
> >    http://www.ozlabs.org/~akpm/mmotm/
> > 
> > mmotm-readme.txt says
> > 
> > README for mm-of-the-moment:
> > 
> > http://www.ozlabs.org/~akpm/mmotm/
> > 
> > This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> > more than once a week.
> > 
> 
> 
> on x86_64:
> 
> arch/x86/hyperv/hv_apic.o: warning: objtool: hv_apic_write()+0x25: alternative modifies stack

Wheee... this seems to have cured it for me.

---
Subject: objtool: Allow no-op CFI ops in alternatives
From: Peter Zijlstra <peterz@...radead.org>
Date: Fri May 8 12:34:33 CEST 2020

Randy reported a false-positive: "alternative modifies stack".

What happens is that:

	alternative_io("movl %0, %P1", "xchgl %0, %P1", X86_BUG_11AP,
 13d:   89 9d 00 d0 7f ff       mov    %ebx,-0x803000(%rbp)

decodes to an instruction with CFI-ops because it modifies RBP.
However, due to this being a !frame-pointer build, that should not in
fact change the CFI state.

So instead of dis-allowing any CFI-op, verify the op would've actually
changed the CFI state.

Fixes: 7117f16bf460 ("objtool: Fix ORC vs alternatives")
Reported-by: Randy Dunlap <rdunlap@...radead.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
---
 tools/objtool/check.c |   11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2078,17 +2078,18 @@ static int handle_insn_ops(struct instru
 	struct stack_op *op;
 
 	list_for_each_entry(op, &insn->stack_ops, list) {
+		struct cfi_state old_cfi = state->cfi;
 		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;
 
+		if (insn->alt_group && memcmp(&state->cfi, &old_cfi, sizeof(struct cfi_state))) {
+			WARN_FUNC("alternative modifies stack", insn->sec, insn->offset);
+			return -1;
+		}
+
 		if (op->dest.type == OP_DEST_PUSHF) {
 			if (!state->uaccess_stack) {
 				state->uaccess_stack = 1;