linux-kernel - Re: [RFC PATCH 0/3] kallsyms: add option to include relative filepaths into kallsyms

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:   Thu, 18 Aug 2022 14:20:06 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Alexander Lobakin <alexandr.lobakin@...el.com>
Cc:     linux-kernel@...r.kernel.org,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
        Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        Petr Mladek <pmladek@...e.com>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        linux-kbuild@...r.kernel.org, live-patching@...r.kernel.org,
        lkp@...el.com, stable@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] kallsyms: add option to include relative
 filepaths into kallsyms

On Thu, Aug 18, 2022 at 01:53:03PM +0200, Alexander Lobakin wrote:
> This is an early RFC to not rewrite stuff one more time later on if
> the implementation is not acceptable or any major design changes are
> required. For the TODO list, please scroll to the end.
> 
> Make kallsyms independent of symbols positions in vmlinux (or module)
> by including relative filepath in each symbol's kallsyms value. I.e.
> 
> dev_gro_receive -> net/core/gro.c:dev_gro_receive
> 
> For the implementation details, please look at the patch 3/3.
> Patch 2/3 is just a stub, I plan to reuse kallsyms enhancement from
> the Rust series for it.
> Patch 1/3 is a fix of one modpost macro straight from 2.6.12-rc2.
> 
> A nice side effect is that it's now easier to debug the kernel, as
> stacktraces will now tell every call's place in the file tree:

That's a side effect, but that does not explain _why_ you want this
change.

What is this good for?  Who can use it?  Why is it worth added build
times?

You don't tell us anything except what this does :(

thanks,

greg k-h