netdev - Re: [PATCH bpf-next v2 3/6] bpf: support attaching freplace programs to multiple attach points

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, 20 Jul 2020 15:57:27 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 3/6] bpf: support attaching freplace programs
 to multiple attach points

On Fri, Jul 17, 2020 at 12:52:10PM +0200, Toke Høiland-Jørgensen wrote:
> 
> > It's a circular reference, obviously.
> > Need to think through the complications and locking.
> 
> Yup, will do so when I get back to this. One other implication of this
> change: If we make the linked_prog completely dynamic you can no longer
> do:
> 
> link_fd = bpf_raw_tracepoint_open(prog);
> close(link_fd);
> link_fd = bpf_raw_tracepoint_open(prog):
> 
> since after that close(), the original linked_prog will be gone. Unless
> we always leave at least one linked_prog alive? But then we can't
> guarantee that it's the target that was supplied on program load if it
> was reattached. Is that acceptable?

I think both options are fine.
We can start with simple case where close would destroy the last link
and if somebody complains we can keep 'at least one alive'.
This is such low level implementation detail that I don't think any user
can reliably count on it staying this way.