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]

Date: Tue, 3 Oct 2023 15:22:05 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: John Fastabend <john.fastabend@...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 Tue, Oct 3, 2023 at 5:42 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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..

David can correct me, but when he tried the SO_RCVLOWAT approach to
solving this problem, he saw no improvements (and it might have
actually been a regression in terms of behavior). I'd say that this
sounds a bit suspicious and we have plans to get back to SO_RCVLOWAT
and try to understand the behavior a bit better.

I'll just say that the simpler the solution - the better. And if this
rcvlowat hook gets us the ability to delay network notification to
user-space until a full logical packet (where packet size is provided
by BPF program without user space involvement) is assembled (up to
some reasonable limits, of course), that would be great.