linux-kernel - Re: [PATCH bpf-next v3] bpf: make the attach target more accurate

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

Message-ID: <324a7b0b-ccff-4d8b-b0a2-f810e90f74f8@linux.dev>
Date: Tue, 15 Jul 2025 07:32:05 +0800
From: Menglong Dong <menglong.dong@...ux.dev>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Menglong Dong <menglong8.dong@...il.com>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
 Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
 bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
 Menglong Dong <dongml2@...natelecom.cn>
Subject: Re: [PATCH bpf-next v3] bpf: make the attach target more accurate


On 2025/7/15 06:29, Alexei Starovoitov wrote:
> On Mon, Jul 14, 2025 at 2:50 PM Menglong Dong <menglong.dong@...ux.dev> wrote:
>>
>> On 2025/7/15 03:52, Alexei Starovoitov wrote:
>>> On Thu, Jul 10, 2025 at 12:10 AM Menglong Dong <menglong8.dong@...il.com> wrote:
>>>>                           } else {
>>>> -                               addr = kallsyms_lookup_name(tname);
>>>> +                               ret = bpf_lookup_attach_addr(NULL, tname, &addr);
>>>>                           }
>>> Not sure why your benchmarking doesn't show the difference,
>>> but above is a big regression.
>>> kallsyms_lookup_name() is a binary search whereas your
>>> bpf_lookup_attach_addr() is linear.
>>> You should see a massive degradation in multi-kprobe attach speeds.
>>
>> Hi, Alexei. Like I said above, the benchmarking does have
>> a difference for the symbol in the modules, which makes
>> the attachment time increased from 0.135543s to 0.176904s
>> for 8631 symbols. As the symbols in the modules
>> is not plentiful, which makes the overhead slight(or not?).
>>
>> But for the symbol in vmlinux, bpf_lookup_attach_addr() will
>> call kallsyms_on_each_match_symbol(), which is also
>> a binary search, so the benchmarking has no difference,
>> which makes sense.
> I see.
> Just curious, what was the function count in modules on your system ?
> cat /proc/kallsyms|grep '\['|grep -v bpf|wc -l

Hi, it's about 34k:

   cat/proc/kallsyms|grep'\['|grep-vbpf|wc-l
   34740


>
> Only now I read the diff carefully enough to realize that
> you're looking for duplicates across vmlinux and that one module.
>
> Why ?
> BTF based attachment identifies a specific module.
> Even if there are dups between that module and vmlinux the attachment
> is not ambiguous.


When the module is not specified, kallsyms_lookup_name() will be called in

bpf_check_attach_target() to get the address. And

kallsyms_lookup_name() will lookup the symbols in the vmlinux

first. If not found, it will lookup it in the modules. And in this

commit, I follow this logic.


So I lookup duplicates accross vmlinux and modules only when

the modules is not specified, and that's reasonable. However,

we always find the address in the vmlinux if module is not specified,

as the btf type belong to the vmlinux. So we will never lookup the

symbols in the modules if "mod" is not specified, which means

bpf_lookup_attach_addr() won't lookup duplicates accross vmlinux
and modules.

So just forget it :/


Thanks!
Menglong Dong


>
>> I thought we don't need this patch after the pahole fixes this
>> problem. Should I send a V4?
> pahole should fix it, so this change is not needed.
> But pahole will be removing the dups within vmlinux and
> within each module independently. Not across them.
> I don't think "across" is needed, but you somehow believe that
> it's necessary ? (based on this diff)