All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Jakub Kicinski <kuba@kernel.org>, Sagi Grimberg <sagi@grimberg.me>
Cc: 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 17:58:39 +0200	[thread overview]
Message-ID: <40bc060f-f359-081d-9ba7-fae531cf2cd6@suse.de> (raw)
In-Reply-To: <20220426080247.19bbb64e@kernel.org>

On 4/26/22 17:02, Jakub Kicinski wrote:
> 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
> 
Count yourself lucky.

> 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.
> 
Well, I'd been surprised that it worked, too.
And even more so that Boris Piskenny @ Nvidia is actively working on it.
(Thanks, Sagi!)

> 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.

Which is precisely what we hope to discuss at LSF.
(Yes, I know, probably not the best venue to discuss network stuff ...)

Each approach has its drawbacks:

- Establishing sockets from userspace will cause issues during 
reconnection, as then someone (aka the kernel) will have to inform 
userspace that a new connection will need to be established.
(And that has to happen while the root filesystem is potentially 
inaccessible, so you can't just call arbitrary commands here)
(Especially call_usermodehelper() is out of the game)
- Having ULP helpers (as with this design) mitigates that problem 
somewhat in the sense that you can mlock() that daemon and having it 
polling on an intermediate socket; that solves the notification problem.
But you have to have ULP special sauce here to make it work.
- Moving everything in kernel is ... possible. But then you have yet 
another security-relevant piece of code in the kernel which needs to be 
audited, CVEd etc. Not to mention the usual policy discussion whether it 
really belongs into the kernel.

So I don't really see any obvious way to go; best we can do is to pick 
the least ugly :-(

Cheers,

Hannes

  reply	other threads:[~2022-04-26 15:58 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 16:49 [PATCH RFC 0/5] Implement a TLS handshake upcall Chuck Lever
2022-04-18 16:49 ` [PATCH RFC 1/5] net: Add distinct sk_psock field Chuck Lever
2022-04-21  7:35   ` Hannes Reinecke
2022-07-13  4:46     ` Hawkins Jiawei
2022-07-13  4:46       ` Hawkins Jiawei
2022-04-18 16:49 ` [PATCH RFC 2/5] tls: build proto after context has been initialized Chuck Lever
2022-04-25 17:11   ` Jakub Kicinski
2022-04-25 17:51     ` Chuck Lever III
2022-05-20 16:39   ` Chuck Lever III
2022-04-18 16:49 ` [PATCH RFC 3/5] net/tls: Add an AF_TLSH address family Chuck Lever
2022-04-21  7:35   ` Hannes Reinecke
2022-04-18 16:49 ` [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Chuck Lever
2022-04-21  7:36   ` Hannes Reinecke
2022-04-25 17:14   ` Jakub Kicinski
2022-04-26  9:43     ` Hannes Reinecke
2022-04-26 14:29       ` Sagi Grimberg
2022-04-26 15:02         ` Jakub Kicinski
2022-04-26 15:58           ` Hannes Reinecke [this message]
2022-04-27  0:03             ` Jakub Kicinski
2022-04-27 15:24               ` Chuck Lever III
2022-04-28  7:26               ` Hannes Reinecke
2022-04-28 13:30                 ` Jakub Kicinski
2022-04-28 13:51                   ` Hannes Reinecke
2022-04-28 14:09                     ` Benjamin Coddington
2022-04-28 21:08                       ` Jakub Kicinski
2022-05-24 10:05                         ` [ovs-dev] " Ilya Maximets
2022-04-26 14:55       ` Jakub Kicinski
2022-04-26 13:48     ` Chuck Lever III
2022-04-26 14:55       ` Jakub Kicinski
2022-04-26 15:58         ` Chuck Lever III
2022-04-26 23:47           ` Jakub Kicinski
2022-04-27 14:42             ` Chuck Lever III
2022-04-27 23:53               ` Jakub Kicinski
2022-04-28  1:29                 ` Chuck Lever III
2022-04-28 21:08                   ` Jakub Kicinski
2022-04-28 21:54                     ` Chuck Lever III
2022-04-28  8:49   ` Boris Pismenny
2022-04-28 13:12     ` Simo Sorce
2022-04-29 15:19       ` Chuck Lever III
2022-04-28 15:24     ` Chuck Lever III
2022-04-29  6:25       ` Hannes Reinecke
2022-04-18 16:49 ` [PATCH RFC 5/5] net/tls: Add observability for AF_TLSH sockets Chuck Lever
2022-04-21  7:36   ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40bc060f-f359-081d-9ba7-fae531cf2cd6@suse.de \
    --to=hare@suse.de \
    --cc=ak@tempesta-tech.com \
    --cc=borisp@nvidia.com \
    --cc=chuck.lever@oracle.com \
    --cc=kuba@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=sagi@grimberg.me \
    --cc=simo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.