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 14:01:09 -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:53 PM, Daniel Borkmann wrote:
> 
> I think it depends on the environment, and yes, whether the orchestrator
> of those progs controls the host [networking] as in case of Cilium. We
> actually had cases where a large user in prod was accidentally removing
> the Cilium k8s daemon set (and hence the user space agent as well) and only
> noticed 1hrs later since everything just kept running in the data path as
> expected w/o causing them an outage. So I think both attachment semantics
> have pros and cons. ;)

of course. that's why there is pinning of FD-based links.
There are cases where pinning is useful and there are cases where
pinning will cause outages.
During app restart temporary pinning might be useful too.

> But then are you also expecting that netlink requests which drop that tc
> filter that holds this BPF prog would get rejected given it has a bpf_link,
> is active & pinned and traffic goes through? If not the case, then what
> would be the point? If it is the case, then this seems rather complex to
> realize for rather little gain given there are two uapi interfaces (bpf,
> tc/netlink) which then mess around with the same underlying object in
> different ways.

Legacy api for tc, xdp, cgroup will not be able to override FD-based
link. For TC it's easy. cls-bpf allows multi-prog, so netlink
adding/removing progs will not be able to touch progs that are
attached via FD-based link.
Same thing for cgroups. FD-based link will be similar to 'multi' mode.
The owner of the link has a guarantee that their program will
stay attached to cgroup.
XDP is also easy. Since it has only one prog. Attaching FD-based link
will prevent netlink from overriding it.
This way the rootlet prog installed by libxdp (let's find a better name
for it) will stay attached. libxdp can choose to pin it in some libxdp
specific location, so other libxdp-enabled applications can find it
in the same location, detach, replace, modify, but random app that
wants to hack an xdp prog won't be able to mess with it.
We didn't come up with these design choices overnight. It came from
hard lessons learned while deploying xdp, tc and cgroup in production.
Legacy apis will not be deprecated, of course.