All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Sagi Grimberg <sagi@grimberg.me>,
	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: Thu, 28 Apr 2022 09:26:41 +0200	[thread overview]
Message-ID: <23f497ab-08e3-3a25-26d9-56d94ee92cde@suse.de> (raw)
In-Reply-To: <20220426170334.3781cd0e@kernel.org>

On 4/27/22 02:03, Jakub Kicinski wrote:
> On Tue, 26 Apr 2022 17:58:39 +0200 Hannes Reinecke wrote:
>>> 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 ...)
> 
> Indeed.
> 
>> 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)
> 
> Indeed, we may need _some_ form of a notification mechanism and that's
> okay. Can be a (more generic) socket, can be something based on existing
> network storage APIs (IDK what you have there).
> 
Which is one of the issues; we don't have any.
Network storage is accessed from userspace via read()/write(), and for 
control everyone rolls its own thing.
So speaking of a 'network storage API' is quite optimistic.

> My thinking was that establishing the session in user space would be
> easiest. We wouldn't need all the special getsockopt()s which AFAIU
> work around part of the handshake being done in the kernel, and which,
> I hope we can agree, are not beautiful.
> 
Well; that is open to debate.
During open-iscsi development (which followed your model of having a 
control- and dataplane split between userspace and kernel) we found that 
the model is great for keeping the in-kernel code simple.
But we also found that it's not so great once you come down to the 
gritty details; you have to duplicate quite some protocol handling in 
userspace, and you have to worry about session re-establishment.
Up to the point where we start wondering if moving things into userspace 
was a good idea at all...

As for this particular interface: the problem we're facing is that TLS 
has to be started in-band. For some reason NVMexpress decided not to 
follow the traditional method of establishing the socket, start TLS, and 
then start protocol processing, but it rather has specified a hybrid 
model: establishing the socket, doing authentication, _then_ start TLS, 
and only then continue with protocol processing on the TLS socket.

Moving _that_ into userspace would require us to move the most of the 
protocol logic into userspace, too. Which really is something we want to 
avoid, as this would be quite a code duplication.
Not to mention the maintenance burden, as issues would need to be fixed 
in two locations.
(Talk to me about iscsiuio.)

And that's before we even get to things like TLS session tickets, which 
opens yet another can of worms.

>> - 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.
> 
> TBH I don't see how this is much different to option 1 in terms of
> constraints & requirements on the user space agent. We can implement
> option 1 over a socket-like interface, too, and that'll carry
> notifications all the same.
> 
>> - 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.
> 
> Yeah, if that gets posted it'd be great if it includes removing me from
> the TLS maintainers 'cause I want to sleep at night ;)
> 
>> So I don't really see any obvious way to go; best we can do is to pick
>> the least ugly :-(
> 
> True, I'm sure we can find some middle ground between 1 and 2.
> Preferably implemented in a way where the mechanism is separated
> from the fact it's carrying TLS handshake requests, so that it can
> carry something else tomorrow.
> 
Which was actually our goal.
The whole thing started off with the problem on _how_ sockets could be 
passed between kernel and userspace and vice versa.
While there is fd passing between processes via AF_UNIX, there is no 
such mechanism between kernel and userspace.

So accept() was an easy way out as the implementation was quite simple.
And it was moved into net/tls as this was the primary use-case.
But it's by no means meant to be exclusive for TLS; we could expand it 
to other things once there is a need.
But we really didn't want to over-engineer things here.

However, if you have another idea, by all means, do tell.
It's just that I don't think creating sockets in userspace is a great 
fit for us.

Cheers,

Hannes

  parent reply	other threads:[~2022-04-28  7:26 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
2022-04-27  0:03             ` Jakub Kicinski
2022-04-27 15:24               ` Chuck Lever III
2022-04-28  7:26               ` Hannes Reinecke [this message]
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=23f497ab-08e3-3a25-26d9-56d94ee92cde@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 \
    --subject='Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)' \
    /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

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.