netdev - RE: [PATCH bpf-next v7 05/11] bpf, sockmap: Don't set up upcalls and progs for listening sockets

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:   Thu, 20 Feb 2020 19:42:07 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Jakub Sitnicki <jakub@...udflare.com>, bpf@...r.kernel.org
Cc:     netdev@...r.kernel.org, kernel-team@...udflare.com,
        John Fastabend <john.fastabend@...il.com>,
        Lorenz Bauer <lmb@...udflare.com>, Martin Lau <kafai@...com>
Subject: RE: [PATCH bpf-next v7 05/11] bpf, sockmap: Don't set up upcalls and
 progs for listening sockets

Jakub Sitnicki wrote:
> Now that sockmap/sockhash can hold listening sockets, when setting up the
> psock we will (i) grab references to verdict/parser progs, and (2) override
> socket upcalls sk_data_ready and sk_write_space.
> 
> However, since we cannot redirect to listening sockets so we don't need to
> link the socket to the BPF progs. And more importantly we don't want the
> listening socket to have overridden upcalls because they would get
> inherited by child sockets cloned from it.
> 
> Introduce a separate initialization path for listening sockets that does
> not change the upcalls and ignores the BPF progs.
> 
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>
> ---
>  net/core/sock_map.c | 52 +++++++++++++++++++++++++++++++++++++++------
>  1 file changed, 45 insertions(+), 7 deletions(-)
> 

Interesting, so after this with listen and established socks in
the same map some will inherit the programs attached to the map and
some will not... I think this is OK when socks are added we know their
state so can reason about it. Anyways the same can happen by attaching
programs after socks are added.

It would probably be more confusing to reject listen socks when progs
are attached so seems like the right design choice to me.

Acked-by: John Fastabend <john.fastabend@...il.com>