netdev - Re: [PATCH bpf-next 0/3] Introduce pinnable bpf

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:   Tue, 3 Mar 2020 07:46:54 -0800
From:   Alexei Starovoitov <ast@...com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>
CC:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel
 abstraction

On 3/3/20 12:12 AM, Daniel Borkmann wrote:
> 
> I can see the motivation for this abstraction in particular for tracing, 
> but given
> the goal of bpf_link is to formalize and make the various program 
> attachment types
> more uniform, how is this going to solve e.g. the tc/BPF case? There is 
> no guarantee
> that while you create a link with the prog attached to cls_bpf that 
> someone else is
> going to replace that qdisc underneath you, and hence you end up with 
> the same case
> as if you would have only pinned the program itself (and not a link). So 
> bpf_link
> then gives a wrong impression that something is still attached and 
> active while it
> is not. What is the plan for these types?

TC is not easy to handle, right, but I don't see a 'wrong impression' 
part. The link will keep the program attached to qdisc. The admin
may try to remove qdisc for netdev, but that's a separate issue.
Same thing with xdp. The link will keep xdp program attached,
but admin may do ifconfig down and no packets will be flowing.
Similar with cgroups. The link will keep prog attached to a cgroup,
but admin can still do rmdir and cgroup will be in 'dying' state.
In case of tracing there is no intermediate entity between programs
and the kernel. In case of networking there are layers.
Netdevs, qdiscs, etc. May be dev_hold is a way to go.