linux-kernel - [PATCH 0/2] Fix objtool error reporting and handling of very long symbol names

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

Date:   Wed, 4 Oct 2023 17:08:17 -0700
From:   Aaron Plattner <aplattner@...dia.com>
To:     <linux-kernel@...r.kernel.org>
CC:     Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Aaron Plattner <aplattner@...dia.com>
Subject: [PATCH 0/2] Fix objtool error reporting and handling of very long symbol names

Two patches in this series:

First, when objtool encounters an error, it carefully propagates the return
code all the way up to main(), which proceeds to ignore it and return 0 no
matter what. This can cause problems with objtool to be missed because the
overall build succeeds. This appears to be a regression in commit
b51277eb9775c, which dropped a call to exit(ret) when a subcommand fails.

Fix that by returning the status code from main().

Second, very long symbol names with .cold variants cause objtool to fail.
This is due to using a small max length, which in turn is due to allocating
on the stack. However, there is not actually a requirement to allocate on
the stack in this (user space) code path, and in fact, the code is cleaner
with this fix: MAX_NAME_LEN is gone and the ugly manual NULL termination
is also removed.

The net result is a more capable objtool and slightly cleaner code.

Although this fix technically only applies to drivers that generate
unusually long symbol names, typically due to using C++ (and these cases
only appear to exist outside of the kernel tree so far), I think it's still
worth applying. That's because the net result is a more capable objtool:
one that lacks an arbitrary length limit for symbol names.

For example, Rust support is being added, and drivers will be the first
users of that support. And like C++, Rust also needs to mangle names [1].
So getting rid of the name length constraint is just good hygiene.

[1] https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html 

Aaron Plattner (2):
  objtool: return the result of objtool_run() so the build fails if
    objtool doesn't work
  objtool: use strndup() to avoid the need for a maximum symbol name
    length

 tools/objtool/elf.c     | 14 ++++++--------
 tools/objtool/objtool.c |  4 +---
 2 files changed, 7 insertions(+), 11 deletions(-)

-- 
2.42.0