netdev - Re: Sockmap's parser/verdict programs and epoll notifications

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: <20231003054156.52816535@kernel.org>
Date: Tue, 3 Oct 2023 05:41:56 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: John Fastabend <john.fastabend@...il.com>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>, bpf <bpf@...r.kernel.org>,
 Networking <netdev@...r.kernel.org>, "davidhwei@...a.com"
 <davidhwei@...a.com>
Subject: Re: Sockmap's parser/verdict programs and epoll notifications

On Mon, 02 Oct 2023 22:16:13 -0700 John Fastabend wrote:
> > This with the other piece we want from our side to allow running
> > verdict and sk_msg programs on sockets without having them in a
> > sockmap/sockhash it would seem like a better system to me. The
> > idea to drop the sockmap/sockhash is because we never remove progs
> > once they are added and we add them from sockops side. The filter
> > to socketes is almost always the port + metadata related to the
> > process or environment. This simplifies having to manage the
> > sockmap/sockhash and guess what size it should be. Sometimes we
> > overrun these maps and have to kill connections until we can
> > get more space.

That's a step in the right direction for sure, but I still think that
Google's auto-lowat is the best approach. We just need a hook that
looks at incoming data and sets rcvlowat appropriately. That's it.
TCP looks at rcvlowat in a number of places to make protocol decisions,
not just the wake-up. Plus Google will no longer have to carry their
OOT patch..