Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)

From: Jakub Kicinski <kuba@kernel.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Hannes Reinecke <hare@suse.de>,
	Chuck Lever <chuck.lever@oracle.com>,
	netdev@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-cifs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, ak@tempesta-tech.com,
	borisp@nvidia.com, simo@redhat.com
Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)
Date: Tue, 26 Apr 2022 08:02:47 -0700	[thread overview]
Message-ID: <20220426080247.19bbb64e@kernel.org> (raw)
In-Reply-To: <1fca2eda-83e4-fe39-13c8-0e5e7553689b@grimberg.me>

On Tue, 26 Apr 2022 17:29:03 +0300 Sagi Grimberg wrote:
> >> Create the socket in user space, do all the handshakes you need there
> >> and then pass it to the kernel.  This is how NBD + TLS works.  Scales
> >> better and requires much less kernel code.
> >>  
> > But we can't, as the existing mechanisms (at least for NVMe) creates the 
> > socket in-kernel.
> > Having to create the socket in userspace would require a completely new 
> > interface for nvme and will not be backwards compatible.  
> 
> And we will still need the upcall anyways when we reconnect 
> (re-establish the socket)

That totally flew over my head, I have zero familiarity with in-kernel
storage network users :S

In all honesty the tls code in the kernel is a bit of a dumping ground.
People come, dump a bunch of code and disappear. Nobody seems to care
that the result is still (years in) not ready for production use :/
Until a month ago it'd break connections even under moderate memory
pressure. This set does not even have selftests.

Plus there are more protocols being actively worked on (QUIC, PSP etc.)
Having per ULP special sauce to invoke a user space helper is not the
paradigm we chose, and the time as inopportune as ever to change that.