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

Message-ID: <53ab50de-04e0-48b1-af19-f1dbf60b0927@oracle.com>
Date: Wed, 27 Aug 2025 20:52:00 +0100
From: Alan Maguire <alan.maguire@...cle.com>
To: Eduard Zingerman <eddyz87@...il.com>,
        Yonghong Song <yonghong.song@...ux.dev>,
        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 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
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
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