netdev - Re: [Potential Spoof] [PATCH bpf-next] libbpf: add bpf_link__disconnect() API to preserve underlying BPF resource

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]

Date:   Wed, 18 Dec 2019 23:12:19 +0000
From:   Martin Lau <kafai@...com>
To:     Andrii Nakryiko <andriin@...com>
CC:     "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "andrii.nakryiko@...il.com" <andrii.nakryiko@...il.com>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [Potential Spoof] [PATCH bpf-next] libbpf: add
 bpf_link__disconnect() API to preserve underlying BPF resource

On Wed, Dec 18, 2019 at 02:50:39PM -0800, Andrii Nakryiko wrote:
> There are cases in which BPF resource (program, map, etc) has to outlive
> userspace program that "installed" it in the system in the first place.
> When BPF program is attached, libbpf returns bpf_link object, which
> is supposed to be destroyed after no longer necessary through
> bpf_link__destroy() API. Currently, bpf_link destruction causes both automatic
> detachment and frees up any resources allocated to for bpf_link in-memory
> representation. This is inconvenient for the case described above because of
> coupling of detachment and resource freeing.
> 
> This patch introduces bpf_link__disconnect() API call, which marks bpf_link as
> disconnected from its underlying BPF resouces. This means that when bpf_link
> is destroyed later, all its memory resources will be freed, but BPF resource
> itself won't be detached.
> 
> This design allows to follow strict and resource-leak-free design by default,
> while giving easy and straightforward way for user code to opt for keeping BPF
> resource attached beyond lifetime of a bpf_link. For some BPF programs (i.e.,
> FS-based tracepoints, kprobes, raw tracepoint, etc), user has to make sure to
> pin BPF program to prevent kernel to automatically detach it on process exit.
> This should typically be achived by pinning BPF program (or map in some cases)
> in BPF FS.
Thanks for the patch.

Acked-by: Martin KaFai Lau <kafai@...com>