netdev - Re: [PATCH bpf-next] bpf: Add LINK_DETACH for iter and perf links

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: <aJOhPoTLdYnZmHYA@der-flo.net>
Date: Wed, 6 Aug 2025 20:38:54 +0200
From: Florian Lehner <dev@...-flo.net>
To: Yonghong Song <yonghong.song@...ux.dev>
Cc: bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
	andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com,
	song@...nel.org, john.fastabend@...il.com, kpsingh@...nel.org,
	sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org,
	davem@...emloft.net, kuba@...nel.org, hawk@...nel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH bpf-next] bpf: Add LINK_DETACH for iter and perf links

On Tue, Aug 05, 2025 at 02:07:20PM -0700, Yonghong Song wrote:
> 
> 
> On 8/1/25 5:10 AM, Florian Lehner wrote:
> > 73b11c2a introduced LINK_DETACH and implemented it for some link types,
> > like xdp, netns and others.
> > 
> > This patch implements LINK_DETACH for perf and iter links, re-using
> > existing link release handling code.
[..]
> >   static void bpf_iter_link_dealloc(struct bpf_link *link)
> >   {
> >   	struct bpf_iter_link *iter_link =
> > @@ -490,6 +496,7 @@ static int bpf_iter_link_fill_link_info(const struct bpf_link *link,
> >   static const struct bpf_link_ops bpf_iter_link_lops = {
> >   	.release = bpf_iter_link_release,
> > +	.detach = bpf_iter_link_detach,
> 
> Not sure how useful for this one. For bpf_iter programs,
> the loaded prog will expect certain bpt_iter (e.g., bpf_map_elem, bpf_map, ...).
> So even if you have detach, you won't be able to attach to a different
> bpf_iter flavor.
> 
> Do you have a use case for this one?
> 

A key reason for adding this was to enable the temporary disabling and re-enabling of
an attached BPF program while keeping the same bpf_iter flavor. If you don't think
this is a strong enough use case, I'm open to removing this from the patch.

> >   static void bpf_perf_link_dealloc(struct bpf_link *link)
> >   {
> >   	struct bpf_perf_link *perf_link = container_of(link, struct bpf_perf_link, link);
> > @@ -4027,6 +4033,7 @@ static void bpf_perf_link_show_fdinfo(const struct bpf_link *link,
> >   static const struct bpf_link_ops bpf_perf_link_lops = {
> >   	.release = bpf_perf_link_release,
> > +	.detach = bpf_perf_link_detach,
> 
> This one may be possible. You might be able to e.g., try a different bpf_cookie, or
> different perf event.
>

The primary use case for this feature is to allow for the temporary disabling of
uprobes that are attached using bpf_perf_links.