netdev - Re: [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup

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: <5e6968eb5c09c_20552ab9153405b419@john-XPS-13-9370.notmuch>
Date:   Wed, 11 Mar 2020 15:40:43 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Jakub Sitnicki <jakub@...udflare.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Lorenz Bauer <lmb@...udflare.com>, kernel-team@...udflare.com,
        netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH 0/5] Return fds from privileged sockhash/sockmap lookup

Jakub Sitnicki wrote:
> On Tue, Mar 10, 2020 at 06:47 PM CET, Lorenz Bauer wrote:
> > We want to use sockhash and sockmap to build the control plane for
> > our upcoming BPF socket dispatch work. We realised that it's
> > difficult to resize or otherwise rebuild these maps if needed,
> > because there is no way to get at their contents. This patch set
> > allows a privileged user to retrieve fds from these map types,
> > which removes this obstacle.
> 
> Since it takes just a few lines of code to get an FD for a sock:
> 
> 	fd = get_unused_fd_flags(O_CLOEXEC);
> 	if (unlikely(fd < 0))
> 		return fd;
>         fd_install(fd, get_file(sk->sk_socket->file));
> 
> ... I can't help but wonder where's the catch?
> 
> IOW, why wasn't this needed so far?
> How does Cilium avoid resizing & rebuilding sockmaps?

I build a map at init time and pin it for the lifetime of the daemon.
If we overrun the sockmap we can always fall back to the normal case
so there has never been a reason to resize.

I guess being able to change the map size at runtime would be a nice
to have but we don't do this with any other maps, e.g. connection
tracking, load balancing, etc. We expect good-sizing upfront. 

@Lorenz, Would it be possible to provide some more details where a
resize would be used? I guess if the map is nearly full you could
rebuild a bigger one and migrate? One thing I explored at one point
is to just create a new map and use multiple maps in the datapath
but that required extra lookups and for hashing might not be ideal.

> 
> Just asking out of curiosity.
> 
> [...]