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]
Message-ID: <20200720225727.zs7x63u3f3kw3apt@ast-mbp.dhcp.thefacebook.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ