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: <FE4F231A-5D24-4337-AE00-9B251733EC53@fb.com>
Date: Fri, 2 Aug 2024 03:45:42 +0000
From: Song Liu <songliubraving@...a.com>
To: "Leizhen (ThunderTown)" <thunder.leizhen@...weicloud.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>, Petr Mladek
	<pmladek@...e.com>,
        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.



> On Aug 1, 2024, at 6:18 PM, Leizhen (ThunderTown) <thunder.leizhen@...weicloud.com> wrote:
> 
> On 2024/7/31 9:00, Song Liu wrote:
>> Hi Masami, 
>> 
>>> On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu <mhiramat@...nel.org> wrote:
>>> 
>>> On Mon, 29 Jul 2024 17:54:32 -0700
>>> Song Liu <song@...nel.org> wrote:
>>> 
>>>> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
>>>> to avoid duplication. This causes confusion with users of kallsyms.
>>>> On one hand, users like livepatch are required to match the symbols
>>>> exactly. On the other hand, users like kprobe would like to match to
>>>> original function names.
>>>> 
>>>> Solve this by splitting kallsyms APIs. Specifically, existing APIs now
>>>> should match the symbols exactly. Add two APIs that matches the full
>>>> symbol, or only the part without .llvm.suffix. Specifically, the following
>>>> two APIs are added:
>>>> 
>>>> 1. kallsyms_lookup_name_or_prefix()
>>>> 2. kallsyms_on_each_match_symbol_or_prefix()
>>> 
>>> Since this API only removes the suffix, "match prefix" is a bit confusing.
>>> (this sounds like matching "foo" with "foo" and "foo_bar", but in reality,
>>> it only matches "foo" and "foo.llvm.*")
>>> What about the name below?
>>> 
>>> kallsyms_lookup_name_without_suffix()
>>> kallsyms_on_each_match_symbol_without_suffix()
>> 
>> I am open to name suggestions. I named it as xx or prefix to highlight
>> that these two APIs will try match full name first, and they only match
>> the symbol without suffix when there is no full name match. 
>> 
>> Maybe we can call them: 
>> - kallsyms_lookup_name_or_without_suffix()
>> - kallsyms_on_each_match_symbol_or_without_suffix()
>> 
>> Again, I am open to any name selections here.
> 
> Only static functions have suffixes. In my opinion, explicitly marking static
> might be a little clearer.
> kallsyms_lookup_static_name()
> kallsyms_on_each_match_static_symbol()

While these names are shorter, I think they are more confusing. Not all
folks know that only static functions can have suffixes. 

Maybe we should not hide the "try match full name first first" in the
API, and let the users handle it. Then, we can safely call the new APIs
*_without_suffix(), as Masami suggested. 

If there is no objections, I will send v2 based on this direction. 

Thanks,
Song