linux-kernel - Re: [PATCH 2/3] kallsyms: Add APIs to match symbol without .llmv.<hash> suffix.

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]

Message-ID: <2F42C167-319A-46F2-A6C8-95B59F675D65@fb.com>
Date: Fri, 2 Aug 2024 17:09:12 +0000
From: Song Liu <songliubraving@...a.com>
To: Petr Mladek <pmladek@...e.com>
CC: Song Liu <songliubraving@...a.com>,
        Masami Hiramatsu
	<mhiramat@...nel.org>, Song Liu <song@...nel.org>,
        "live-patching@...r.kernel.org" <live-patching@...r.kernel.org>,
        LKML
	<linux-kernel@...r.kernel.org>,
        "linux-trace-kernel@...r.kernel.org"
	<linux-trace-kernel@...r.kernel.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>, Jiri Kosina <jikos@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>,
        Joe Lawrence
	<joe.lawrence@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        "morbo@...gle.com" <morbo@...gle.com>,
        Justin Stitt <justinstitt@...gle.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Leizhen <thunder.leizhen@...wei.com>,
        "kees@...nel.org" <kees@...nel.org>,
        Kernel Team <kernel-team@...a.com>,
        Matthew Maurer <mmaurer@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 2/3] kallsyms: Add APIs to match symbol without
 .llmv.<hash> suffix.

Hi Petr, 

> On Aug 2, 2024, at 8:45 AM, Petr Mladek <pmladek@...e.com> wrote:

[...]

> 
> IMHO, it depends on the use case. Let's keep "ping_table/"
> as an example. Why people would want to trace this function?
> There might be various reasons, for example:
> 
>  1. ping_table.llvm.15394922576589127018 appeared in a backtrace
> 
>  2. ping_table.llvm.15394922576589127018 appeared in a histogram
> 
>  3. ping_table looks interesting when reading code sources
> 
>  4. ping_table need to be monitored on all systems because
>     of security/performance.
> 
> The full name "ping_table.llvm.15394922576589127018" is perfectly
> fine in the 1st and 2nd scenario. People knew this name already
> before they start thinking about tracing.
> 
> The short name is more practical in 3rd and 4th scenario. Especially,
> when there is only one static symbol with this short name. Otherwise,
> the user would need an extra step to find the full name.
> 
> The full name is even more problematic for system monitors. These
> applications might need to probe particular symbols. They might
> have hard times when the symbol is:
> 
>    <symbol_name_from_sources>.<random_suffix_generated_by_compiler>
> 
> They will have to deal with it. But it means that every such tool
> would need an extra (non-trivial) code for this. Every tool would
> try its own approach => a lot of problems.
> 
> IMHO, the two APIs could make the life easier.
> 
> Well, even kprobe might need two APIs to allow probing by
> full name or without the suffix.

The problem is, with potential partial inlining by modern compilers, 
tracing "symbol name from sources" is not accurate. In our production 
kernels, we have to add some explicit "noline" to make sure we can 
trace these functions reliably. 

Of course, this issue exists without random suffix: any function 
could be partially inlined. However, allowing tracing without the 
suffix seems to hint that tracing with "symbol name from sources" 
is valid, which is not really true. 

At the moment, I have no objections to keep the _without_suffix
APIs. But for long term, I still think we need to set clear 
expectations for the users: tracing symbols from sources is not
reliable. 

Thanks,
Song