netdev - Re: [RFC] Socket termination for policy enforcement and load-balancing

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] [day] [month] [year] [list]

Date:   Mon, 12 Sep 2022 11:01:33 +0100
From:   Aditi Ghag <aditivghag@...il.com>
To:     Martin KaFai Lau <martin.lau@...ux.dev>
Cc:     Kumar Kartikeya Dwivedi <memxor@...il.com>,
        Martin KaFai Lau <kafai@...com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Daniel Borkmann <daniel@...earbox.net>,
        Yonghong Song <yhs@...com>,
        Kuniyuki Iwashima <kuniyu@...zon.com>
Subject: Re: [RFC] Socket termination for policy enforcement and load-balancing

On Thu, Sep 8, 2022 at 3:26 AM Martin KaFai Lau <martin.lau@...ux.dev> wrote:
>
> On 9/4/22 2:24 PM, Kumar Kartikeya Dwivedi wrote:
> > On Sun, 4 Sept 2022 at 20:55, Aditi Ghag <aditivghag@...il.com> wrote:
> >>
> >> On Wed, Aug 31, 2022 at 4:02 PM Martin KaFai Lau <kafai@...com> wrote:
> >>>
> >>> On Wed, Aug 31, 2022 at 09:37:41AM -0700, Aditi Ghag wrote:
>>>> [...]
> >>
> >> On a similar note, are there better ways as alternatives to the
> >> sockets iterator approach.
> >> Since we have BPF programs executed on cgroup BPF hooks (e.g.,
> >> connect), we already know what client
> >> sockets are connected to a backend. Can we somehow store these socket
> >> pointers in a regular BPF map, and
> >> when a backend is deleted, use a regular map iterator to invoke
> >> sock_destroy() for these sockets? Does anyone have
> >> experience using the "typed pointer support in BPF maps" APIs [0]?
> >
> > I am not very familiar with how socket lifetime is managed, it may not
> > be possible in case lifetime is managed by RCU only,
> > or due to other limitations.
> > Martin will probably be able to comment more on that.
> sk is the usual refcnt+rcu_reader pattern.  afaik, the use case here is
> the sk should be removed from the map when there is a tcp_close() or
> udp_lib_close().  There is sock_map and sock_hash to store sk as the
> map-value.  iirc the sk will be automatically removed from the map
> during tcp_close() and udp_lib_close().  The sock_map and sock_hash have
> bpf iterator also.  Meaning a bpf-iter-prog can iterate the sock_map and
> sock_hash and then do abort on each sk, so it looks like most of the
> pieces are in place.
>

Yes, I did consider using a sock_hash type map. But for some reason I
thought it would be
accessible only from bpf_prog_type_sk_skb or sockops. Looks like the
regular map helpers
can be used for update/lookup operations on sock_hash map type. It's
great to know that sock
ref counting in sock map/hash types are automatically accounted for,
so we don't have to add
additional INET sock_release hooks.