netdev - Re: [PATCH bpf-next v3 1/7] netkit, bpf: Add bpf programmable net device

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: <ca1f0aaa-94c2-5e7d-1d00-a640bb3be44a@iogearbox.net>
Date: Tue, 24 Oct 2023 20:05:20 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Stanislav Fomichev <sdf@...gle.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, martin.lau@...ux.dev,
 razor@...ckwall.org, ast@...nel.org, andrii@...nel.org,
 john.fastabend@...il.com, toke@...nel.org, kuba@...nel.org, andrew@...n.ch
Subject: Re: [PATCH bpf-next v3 1/7] netkit, bpf: Add bpf programmable net
 device

On 10/24/23 6:40 PM, Stanislav Fomichev wrote:
> On 10/23, Daniel Borkmann wrote:
[...]
> The series looks great! FWIW:
> Acked-by: Stanislav Fomichev <sdf@...gle.com>

Thanks for review!

> One small question I have is:
> We now (and after introduction of tcx) seem to store non-refcounted
> dev pointers in the bpf_link(s). Is it guaranteed that the dev will
> outlive the link?

The semantics are the same as it was done in XDP, meaning, the link is in
detached state so link->dev is NULL when dev goes away, see also the
dev_xdp_uninstall(). We cannot hold a refcount on the dev as otherwise
if the link outlives it we get the infamous "unregister_netdev...waiting
for <dev>... refcnt = 1" bug.

>> +	ret = netkit_link_prog_attach(&nkl->link,
>> +				      attr->link_create.flags,
>> +				      attr->link_create.netkit.relative_fd,
>> +				      attr->link_create.netkit.expected_revision);
>> +	if (ret) {
>> +		nkl->dev = NULL;
>> +		bpf_link_cleanup(&link_primer);
>> +		goto out;
> 
> What happens to nkl here? Do we leak it?

No, this is done similarly as in XDP and tcx, that is, bpf_link_cleanup() will
trigger eventual release of nlk here :

/* Clean up bpf_link and corresponding anon_inode file and FD. After
  * anon_inode is created, bpf_link can't be just kfree()'d due to deferred
  * anon_inode's release() call. This helper marks bpf_link as
  * defunct, releases anon_inode file and puts reserved FD. bpf_prog's refcnt
  * is not decremented, it's the responsibility of a calling code that failed
  * to complete bpf_link initialization.
  * This helper eventually calls link's dealloc callback, but does not call
  * link's release callback.
  */

Thanks,
Daniel