Re: pull-request: bpf-next 2023-12-18

Re: pull-request: bpf-next 2023-12-18

[Jakub Kicinski]

On Mon, 18 Dec 2023 16:05:20 -0800 Alexei Starovoitov wrote:
> 2) Introduce BPF token object, from Andrii Nakryiko.
> It adds an ability to delegate a subset of BPF features from privileged daemon
> (e.g., systemd) through special mount options for userns-bound BPF FS to a
> trusted unprivileged application. The design accommodates suggestions from
> Christian Brauner and Paul Moore.
> Example:
> $ sudo mkdir -p /sys/fs/bpf/token
> $ sudo mount -t bpf bpffs /sys/fs/bpf/token \
>              -o delegate_cmds=prog_load:MAP_CREATE \
>              -o delegate_progs=kprobe \
>              -o delegate_attachs=xdp

LGTM, but what do I know about file systems.. Adding LKML to the CC
list, if anyone has any late comments on the BPF token come forward
now, petty please?

Re: pull-request: bpf-next 2023-12-18

[Linus Torvalds]

On Mon, 18 Dec 2023 at 16:55, Jakub Kicinski <kuba@kernel.org> wrote:
>
> LGTM, but what do I know about file systems.. Adding LKML to the CC
> list, if anyone has any late comments on the BPF token come forward
> now, petty please?

See my crossed email reply.

The file descriptor handling is FUNDAMENTALLY wrong. The first time
that happened, we chalked it up to a mistake. Now it's something
worse.

Please don't pull until at least that part is fixed.

I tried to review the token patches, but honestly, I got to that part
and I just gave up.

We had this whole discussion more than 6 months ago:

  https://lore.kernel.org/all/20230517-allabendlich-umgekehrt-8cc81f8313ac@brauner/

and I really thought the bpf people had *understood* they their
special use of "fd == 0" was wrong.

But it seems that they never did. Once is a mistake. Twice is a
choice. And the bpf people have chosen insanity.

               Linus