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: <aK63i7yvJFKkcDpw@gpd4>
Date: Wed, 27 Aug 2025 09:45:15 +0200
From: Andrea Righi <arighi@...dia.com>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: Yonghong Song <yonghong.song@...ux.dev>,
	Alexei Starovoitov <ast@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>,
	Andrii Nakryiko <andrii@...nel.org>,
	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 Wed, Aug 27, 2025 at 12:01:09AM -0700, Eduard Zingerman wrote:
> On Tue, 2025-08-26 at 23:52 -0700, Eduard Zingerman wrote:
> 
> [...]
> 
> > If we are being really paranoid about LTO builds, is __noclone sufficient?
> > E.g. [1] does not imply that signature can't be changed.
> > We currently apply only __retain__, here is a little test with both attributes:
> 
> Nope, there are also 'used' and 'noinline' applied.
> With these the function is preserved as expected.
> Sorry for the noise.

Yeah, 'used' forces the function to be emitted even if it appears
unreferenced. Together with 'noclone', 'retain' and 'noinline', should
ensure the symbol exists and can be reliably found by resolve_btfids.

We could be extra paranoid and mimic EXPORT_SYMBOL(), moving the symbols to
their own section, but in practice I don't think this is strictly
necessary, even in presence of aggressive compiler / LTO optimizations.

Thanks,
-Andrea