linux-kernel - [tip:core/urgent] objtool: Fix STACK_FRAME_NON_STANDARD macro checking for function symbols

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] [day] [month] [year] [list]

Message-ID: <tip-0ea5ad869c85ac604f3e022bf2c5bef54838433b@git.kernel.org>
Date:	Sun, 10 Jul 2016 11:16:02 -0700
From:	tip-bot for Josh Poimboeuf <tipbot@...or.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	mathieu.desnoyers@...icios.com, jpoimboe@...hat.com,
	peterz@...radead.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org, hpa@...or.com,
	torvalds@...ux-foundation.org, tglx@...utronix.de
Subject: [tip:core/urgent] objtool: Fix STACK_FRAME_NON_STANDARD macro
 checking for function symbols

Commit-ID:  0ea5ad869c85ac604f3e022bf2c5bef54838433b
Gitweb:     http://git.kernel.org/tip/0ea5ad869c85ac604f3e022bf2c5bef54838433b
Author:     Josh Poimboeuf <jpoimboe@...hat.com>
AuthorDate: Wed, 15 Jun 2016 15:45:58 -0500
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Sun, 10 Jul 2016 17:15:58 +0200

objtool: Fix STACK_FRAME_NON_STANDARD macro checking for function symbols

Mathieu Desnoyers reported that the STACK_FRAME_NON_STANDARD macro
wasn't working with the lttng_filter_interpret_bytecode() function in
the lttng-modules code.

Usually the relocation created by STACK_FRAME_NON_STANDARD creates a
reference to a section symbol like this:

  Offset              Type            Value               Addend Name
  000000000000000000  X86_64_64       000000000000000000   +3136 .text

But in this case it created a reference to a function symbol:

  Offset              Type            Value               Addend Name
  000000000000000000  X86_64_64       0x00000000000003a0      +0 lttng_filter_interpret_bytecode

To be honest I have no idea what causes gcc to decide to do one over the
other.  But both are valid ELF, so add support for the function symbol.

Reported-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: lttng-dev@...ts.lttng.org
Link: http://lkml.kernel.org/r/9cee42843bc6d94e990a152e4e0319cfdf6756ef.1466023450.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 tools/objtool/builtin-check.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index e8a1e69..25d8031 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -122,10 +122,14 @@ static bool ignore_func(struct objtool_file *file, struct symbol *func)
 
 	/* check for STACK_FRAME_NON_STANDARD */
 	if (file->whitelist && file->whitelist->rela)
-		list_for_each_entry(rela, &file->whitelist->rela->rela_list, list)
-			if (rela->sym->sec == func->sec &&
+		list_for_each_entry(rela, &file->whitelist->rela->rela_list, list) {
+			if (rela->sym->type == STT_SECTION &&
+			    rela->sym->sec == func->sec &&
 			    rela->addend == func->offset)
 				return true;
+			if (rela->sym->type == STT_FUNC && rela->sym == func)
+				return true;
+		}
 
 	/* check if it has a context switching instruction */
 	func_for_each_insn(file, func, insn)