From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
ast@kernel.org, andrii@kernel.org, martin.lau@linux.dev,
razor@blackwall.org, sdf@google.com, john.fastabend@gmail.com,
kuba@kernel.org, dxu@dxuuu.xyz, joe@cilium.io, toke@kernel.org,
davem@davemloft.net, bpf@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 2/7] bpf: Add fd-based tcx multi-prog infra with link support
Date: Tue, 4 Jul 2023 18:38:21 -0400 [thread overview]
Message-ID: <CAM0EoMndiP6c20Q9g+dSFMh+XPJCdCAUzjHPXm6-4mmNJtAH3A@mail.gmail.com> (raw)
In-Reply-To: <15ab0ba7-abf7-b9c3-eb5e-7a6b9fd79977@iogearbox.net>
On Tue, Jul 4, 2023 at 6:01 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 7/4/23 11:36 PM, Jamal Hadi Salim wrote:
> > On Thu, Jun 8, 2023 at 5:25 PM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> >> On Thu, Jun 8, 2023 at 12:46 PM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >>> On Thu, Jun 8, 2023 at 6:12 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >>>> On 6/8/23 3:25 AM, Jamal Hadi Salim wrote:
> [...]
> >>>> BPF links are supported for XDP today, just tc BPF is one of the few
> >>>> remainders where it is not the case, hence the work of this series. What
> >>>> XDP lacks today however is multi-prog support. With the bpf_mprog concept
> >>>> that could be addressed with that common/uniform api (and Andrii expressed
> >>>> interest in integrating this also for cgroup progs), so yes, various hook
> >>>> points/program types could benefit from it.
> >>>
> >>> Is there some sample XDP related i could look at? Let me describe our
> >>> use case: lets say we load an ebpf program foo attached to XDP of a
> >>> netdev and then something further upstream in the stack is consuming
> >>> the results of that ebpf XDP program. For some reason someone, at some
> >>> point, decides to replace the XDP prog with a different one - and the
> >>> new prog does a very different thing. Could we stop the replacement
> >>> with the link mechanism you describe? i.e the program is still loaded
> >>> but is no longer attached to the netdev.
> >>
> >> If you initially attached an XDP program using BPF link api
> >> (LINK_CREATE command in bpf() syscall), then subsequent attachment to
> >> the same interface (of a new link or program with BPF_PROG_ATTACH)
> >> will fail until the current BPF link is detached through closing its
> >> last fd.
> >
> > So this works as advertised. The problem is however not totally solved
> > because it seems we need a process that's alive to hold the ownership.
> > If we had a daemon then that would solve it i think (we dont).
> > Alternatively, you pin the link. The pinning part can be
> > circumvented, unless i misunderstood i,e anybody with the right
> > permissions can remove it.
> >
> > Am I missing something?
>
> It would be either of those depending on the use case, and for pinning
> removal, it would require right permissions/acls. Keep in mind that for
> your application you can also use your own bpffs mount, so you don't
> need to use the default /sys/fs/bpf one in hostns.
This helps for sure - doesnt 100% solve it. It would really be nice if
we could tie in a kerberos-like ticketing system for ownership of the
mount or something even more fine grained like a link. Doesnt have to
be kerberos but anything that would allow a digest of some verifiable
credentials/token to be handed to the kernel for authorization...
cheers,
jamal
> Thanks,
> Daniel
next prev parent reply other threads:[~2023-07-04 22:38 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 19:26 [PATCH bpf-next v2 0/7] BPF link support for tc BPF programs Daniel Borkmann
2023-06-07 19:26 ` [PATCH bpf-next v2 1/7] bpf: Add generic attach/detach/query API for multi-progs Daniel Borkmann
2023-06-08 17:23 ` Stanislav Fomichev
2023-06-08 20:59 ` Andrii Nakryiko
2023-06-08 21:52 ` Stanislav Fomichev
2023-06-08 22:13 ` Andrii Nakryiko
2023-06-08 23:06 ` Stanislav Fomichev
2023-06-08 23:54 ` Alexei Starovoitov
2023-06-09 0:08 ` Andrii Nakryiko
2023-06-09 0:38 ` Stanislav Fomichev
2023-06-09 0:29 ` Toke Høiland-Jørgensen
2023-06-09 6:52 ` Daniel Borkmann
2023-06-09 7:15 ` Daniel Borkmann
2023-06-09 11:04 ` Toke Høiland-Jørgensen
2023-06-09 12:34 ` Timo Beckers
2023-06-09 13:11 ` Toke Høiland-Jørgensen
2023-06-09 14:15 ` Daniel Borkmann
2023-06-09 16:41 ` Stanislav Fomichev
2023-06-09 19:03 ` Andrii Nakryiko
2023-06-10 2:52 ` Daniel Xu
2023-06-09 18:58 ` Andrii Nakryiko
2023-06-09 20:28 ` Toke Høiland-Jørgensen
2023-06-12 11:21 ` Dave Tucker
2023-06-12 12:43 ` Daniel Borkmann
2023-06-09 18:56 ` Andrii Nakryiko
2023-06-09 20:08 ` Alexei Starovoitov
[not found] ` <20230610022721.2950602-1-prankgup@fb.com>
2023-06-10 3:37 ` Alexei Starovoitov
2023-06-09 20:20 ` Toke Høiland-Jørgensen
2023-06-08 20:53 ` Andrii Nakryiko
2023-06-07 19:26 ` [PATCH bpf-next v2 2/7] bpf: Add fd-based tcx multi-prog infra with link support Daniel Borkmann
2023-06-08 1:25 ` Jamal Hadi Salim
2023-06-08 10:11 ` Daniel Borkmann
2023-06-08 19:46 ` Jamal Hadi Salim
2023-06-08 21:24 ` Andrii Nakryiko
2023-07-04 21:36 ` Jamal Hadi Salim
2023-07-04 22:01 ` Daniel Borkmann
2023-07-04 22:38 ` Jamal Hadi Salim [this message]
2023-07-05 7:34 ` Daniel Borkmann
2023-07-06 13:31 ` Jamal Hadi Salim
2023-06-08 17:50 ` Stanislav Fomichev
2023-06-08 21:20 ` Andrii Nakryiko
2023-06-09 3:06 ` Jakub Kicinski
2023-06-07 19:26 ` [PATCH bpf-next v2 3/7] libbpf: Add opts-based attach/detach/query API for tcx Daniel Borkmann
2023-06-08 21:37 ` Andrii Nakryiko
2023-06-07 19:26 ` [PATCH bpf-next v2 4/7] libbpf: Add link-based " Daniel Borkmann
2023-06-08 21:45 ` Andrii Nakryiko
2023-06-07 19:26 ` [PATCH bpf-next v2 5/7] bpftool: Extend net dump with tcx progs Daniel Borkmann
2023-06-07 19:26 ` [PATCH bpf-next v2 6/7] selftests/bpf: Add mprog API tests for BPF tcx opts Daniel Borkmann
2023-06-07 19:26 ` [PATCH bpf-next v2 7/7] selftests/bpf: Add mprog API tests for BPF tcx links Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAM0EoMndiP6c20Q9g+dSFMh+XPJCdCAUzjHPXm6-4mmNJtAH3A@mail.gmail.com \
--to=jhs@mojatatu.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dxu@dxuuu.xyz \
--cc=joe@cilium.io \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
--cc=sdf@google.com \
--cc=toke@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).