netdev - Re: [RFC PATCH bpf-next] bpf: Introduce 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:   Mon, 24 May 2021 22:22:01 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        "David S . Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        John Fastabend <john.fastabend@...il.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next] bpf: Introduce bpf_timer

On Mon, May 24, 2021 at 12:13 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> I second the use of BPF_PROG_TEST_RUN (a.k.a. BPF_PROG_RUN now) to
> "mirror" such APIs to user-space. We have so much BPF-side

Except the expiration time is stored in user-space too if you just
use user-space timers to trigger BPF_PROG_TEST_RUN.
Modifying expiration based on its current value in timer callbacks
is very common. For example in conntrack use case, we want the
GC timer to run sooner in the next run if we get certain amount of
expired items in current run.

> functionality and APIs that reflecting all of that with special
> user-space-facing BPF commands is becoming quite impractical. E.g., a
> long time ago there was a proposal to add commands to push data to BPF
> ringbuf from user-space for all kinds of testing scenarios. We never
> did that because no one bothered enough, but now I'd advocate that a
> small custom BPF program that is single-shot through BPF_PROG_RUN is a
> better way to do this. Similarly for timers and whatever other
> functionality. By doing everything from BPF program we also side-step
> potential subtle differences in semantics between BPF-side and
> user-space-side.

I am confused about what you are saying, because we can already
trigger BPF_PROG_RUN with a user-space timer for a single shot,
with the current kernel, without any modification. So this sounds like
you are against adding any timer on the eBPF side, but on the other
hand, you are secoding to Alexei's patch... I am completely lost.

Very clearly, whatever you described as "single shot" is not what we
want from any perspective.

Thanks.