linux-kernel - Re: [PATCH] bpf: Mark kfuncs as _

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: <7f29deaa-e426-457f-8e93-1fdaa111d3d0@linux.dev>
Date: Wed, 27 Aug 2025 15:28:00 -0700
From: Yonghong Song <yonghong.song@...ux.dev>
To: Alan Maguire <alan.maguire@...cle.com>,
 Eduard Zingerman <eddyz87@...il.com>, Andrea Righi <arighi@...dia.com>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>
Cc: Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, David Vernet <void@...ifault.com>,
 bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: Mark kfuncs as __noclone



On 8/27/25 12:52 PM, Alan Maguire wrote:
> On 27/08/2025 20:41, Eduard Zingerman wrote:
>> On Wed, 2025-08-27 at 20:28 +0100, Alan Maguire wrote:
>>
>> [...]
>>
>>> I'm working on a small 2-patch series at the moment to improve this. The
>>> problem is we currently have no way to associate the DWARF with the
>>> relevant ELF function; DWARF representations of functions do not have
>>> "." suffixes either so we are just matching by name prefix when we
>>> collect DWARF info about a particular function.
>> Oh, I see, there is no way to associate DWARF info with either
>> 'bpf_strnchr' or 'bpf_strnchr.constprop.0' w/o checking address.
>> Thank you.
>>
>>> The series I'm working on uses DWARF addresses to improve the DWARF/ELF
>>> association, ensuring that we don't toss functions that look
>>> inconsistent but just have .part or .cold suffixed components that have
>>> non-matching DWARF function signatures. ".constprop" isn't covered yet
>>> however.
>> Is ".constprop" special, or just has to be allowed as one of the prefixes?
>>
> Yonghong can remind me if I've got this wrong, but .constprop is
> somewhat different from .part/.cold in that the latter aren't really on

For symbol with .cold, it is not a function. It is just a jump target
from another function.

For symbol with .part, it is a actual function, but mostly like its
function signature has changed as it is part of the original
function.

For symbol with .constprop, is a clone of another function but
with less parameters, i.e., some parameters become a constant
inside the .constprop.<n> function.

With gcc build, you can see even more complicated suffixes:
   ffffffff81825bf0 t __remove_instance.part.0.constprop.0
   ffffffff81ed07c0 t eventfd_ctx_fileget.part.0.isra.0
   ...

> function boundaries. Sometimes we want to retain .constprop
> representations since they are function boundaries and sometimes do not
> mess with parameters in incompatible ways. If we can find a good
> heuristic for tossing them when they are not helpful as in the above
> case that would be great, but I'm not sure how to do that without losing

It is indeed very hard to have a good heuristic for those function
with suffixes. '<func>.constprop.<n>' might be easier as you can
check location in the subprogrm, if there is no location, most
likely that parameter has become a constant inside the function.

Currently I am working on llvm to add
   - function with suffixes
   - function with changed signature and without suffixes.

Such infomation should have better mapping from func to
its type.

> BTF representations which are useful. Any suggestions on that would be
> really great; in the meantime I'll try and get the series dealing with
> .part and .cold functions out ASAP. Thanks!
>
> Alan