linux-kernel - Re: [PATCH v2 0/5] kallsyms: Emit symbol for holes in text and fix weak function issue

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7266ee61-3085-74fc-2560-c62fc34c2148@huawei.com>
Date: Sat, 14 Dec 2024 16:37:59 +0800
From: Zheng Yejian <zhengyejian1@...wei.com>
To: Martin Kelly <martin.kelly@...wdstrike.com>, "masahiroy@...nel.org"
	<masahiroy@...nel.org>, "ojeda@...nel.org" <ojeda@...nel.org>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "pasha.tatashin@...een.com"
	<pasha.tatashin@...een.com>, "mhiramat@...nel.org" <mhiramat@...nel.org>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"james.clark@....com" <james.clark@....com>, "mpe@...erman.id.au"
	<mpe@...erman.id.au>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, "nicolas@...sle.eu"
	<nicolas@...sle.eu>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
	"nathan@...nel.org" <nathan@...nel.org>, "npiggin@...il.com"
	<npiggin@...il.com>, "mark.rutland@....com" <mark.rutland@....com>,
	"hpa@...or.com" <hpa@...or.com>, "surenb@...gle.com" <surenb@...gle.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "naveen.n.rao@...ux.ibm.com"
	<naveen.n.rao@...ux.ibm.com>, "kent.overstreet@...ux.dev"
	<kent.overstreet@...ux.dev>, "bp@...en8.de" <bp@...en8.de>,
	"yeweihua4@...wei.com" <yeweihua4@...wei.com>,
	"mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
	"mcgrof@...nel.org" <mcgrof@...nel.org>
CC: Amit Dang <amit.dang@...wdstrike.com>, "linux-modules@...r.kernel.org"
	<linux-modules@...r.kernel.org>, "linux-kbuild@...r.kernel.org"
	<linux-kbuild@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
	"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH v2 0/5] kallsyms: Emit symbol for holes in text and fix
 weak function issue

On 2024/12/14 03:31, Martin Kelly wrote:
> On Thu, 2024-12-12 at 17:52 +0800, Zheng Yejian wrote:
>> On 2024/12/11 04:49, Martin Kelly wrote:
>>>
>>>
>>> Zheng, do you plan to send a v3? I'd be happy to help out with this
>>> patch series if you'd like, as I'm hoping to get this issue
>>> resolved
>>> (though I am not an ftrace expert).
>>
>> Sorry to rely so late. Thanks for your feedback!
>>
>> Steve recently started a discussion of the issue in:
>>
>> https://lore.kernel.org/all/20241015100111.37adfb28@gandalf.local.home/
>> but there's no conclusion.
>>    
>> I can rebase this patch series and send a new version first, and
>> I'm also hoping to get more feedbacks and help to resolve the issue.
>>
> 
> Hi Zheng,
> 
> I may have misunderstood, but based on the final message from Steven, I
> got the sense that the idea listed in that thread didn't work out and
> we should proceed with your current approach.

This patch set attempts to add length information of symbols to kallsyms,
which can then ensure that there is only one valid fentry within the range
of function length.

However, I think this patch set actually has some performance implications,
including：
   1. Adding hole symbols may cause the symbol table to grow significantly;
   2. When parsing fentry tables, excluding invalid fentries through kallsyms lookups
      may also increase boot or module load times slightly.

The direct cause of this issue is the wrong fentry being founded by ftrace_location(),
following the approach of "FTRACE_MCOUNT_MAX_OFFSET", narrowing down the search range
and re-finding may also solve this problem, demo patch like below (not
fully tested):

     diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
     index 9b17efb1a87d..7d34320ca9d1 100644
     --- a/kernel/trace/ftrace.c
     +++ b/kernel/trace/ftrace.c
     @@ -1678,8 +1678,11 @@ unsigned long ftrace_location(unsigned long ip)
                             goto out;
     
                     /* map sym+0 to __fentry__ */
     -               if (!offset)
     +               if (!offset) {
                             loc = ftrace_location_range(ip, ip + size - 1);
     +                       while (loc > ip && loc - ip > FTRACE_MCOUNT_MAX_OFFSET)
     +                               loc = ftrace_location_range(ip, loc - 1);
     +               }
             }

Steve, Peter, what do you think?

> 
> Please consider me an interested party for this patch series, and let
> me know if there's anything I can do to help speed it along (co-
> develop, test, anything else). And of course, thanks very much for your
> work thus far!

-- 
Thanks,
Zheng Yejian