All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever III <chuck.lever@oracle.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev <netdev@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"ak@tempesta-tech.com" <ak@tempesta-tech.com>,
	"borisp@nvidia.com" <borisp@nvidia.com>,
	"simo@redhat.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 01:29:10 +0000	[thread overview]
Message-ID: <F64C2771-663D-4BE7-9EB9-A8859818C7F8@oracle.com> (raw)
In-Reply-To: <20220427165354.2eed6c5b@kernel.org>



> On Apr 27, 2022, at 7:53 PM, Jakub Kicinski <kuba@kernel.org> wrote:
> 
> On Wed, 27 Apr 2022 14:42:53 +0000 Chuck Lever III wrote:
>>> On Apr 26, 2022, at 7:47 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>>>> RPC-with-TLS requires one RPC as a "starttls" token. That could be
>>>> done in user space as part of the handshake, but it is currently
>>>> done in the kernel to enable the user agent to be shared with other
>>>> kernel consumers of TLS. Keep in mind that we already have two
>>>> real consumers: NVMe and RPC-with-TLS; and possibly QUIC.
>>>> 
>>>> You asserted earlier that creating sockets in user space "scales
>>>> better" but did not provide any data. Can we see some? How well
>>>> does it need to scale for storage protocols that use long-lived
>>>> connections?  
>>> 
>>> I meant scale with the number of possible crypto protocols, 
>>> I mentioned three there.  
>> 
>> I'm looking at previous emails. The "three crypto protocols"
>> don't stand out to me. Which ones?
> 
> TLS, QUIC and PSP maybe that was in a different email that what you
> quoted, sorry:
> https://lore.kernel.org/all/20220426080247.19bbb64e@kernel.org/
> 
> PSP:
> https://raw.githubusercontent.com/google/psp/main/doc/PSP_Arch_Spec.pdf

During the design process, we discussed both TLS and QUIC handshake
requirements, which are nearly the same. QUIC will want a TLSv1.3
handshake on a UDP socket, effectively. We can support DTLS in a
similar fashion.

We hope that the proposed design can be used for all of those, and
barring anything unforeseen in the description of PSP you provided,
PSP can be supported as well.

The handshake agent is really only a shim around a TLS library.
There isn't much to it.


> Is it possible to instead create a fd-passing-like structured message
> which could carry the fd and all the relevant context (what goes 
> via the getsockopt() now)?
> 
> The user space agent can open such upcall socket, then bind to
> whatever entity it wants to talk to on the kernel side and read
> the notifications via recv()?

We considered this kind of design. A reasonable place to start there
would be to fabricate new NETLINK messages to do this. I don't see
much benefit over what is done now, it's just a different isomer of
syntactic sugar, but it could be considered.

The issue is how the connected socket is materialized in user space.
accept(2) is the historical way to instantiate an already connected
socket in a process's file table, and seems like a natural fit. When
the handshake agent is done with the handshake, it closes the socket.
This invokes the tlsh_release() function which can check whether the
IV implantation was successful.

So instead of an AF_TLSH listener we could use a named pipe or a
netlink socket and a blocking recv(), as long as there is a reasonable
solution to how a connected socket fd is attached to the handshake
agent process.

I'm flexible about the mechanism for passing handshake parameters.
Attaching them to the connected socket seems convenient, but perhaps
not aesthetic.


--
Chuck Lever




  reply	other threads:[~2022-04-28  1:29 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
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 [this message]
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=F64C2771-663D-4BE7-9EB9-A8859818C7F8@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=ak@tempesta-tech.com \
    --cc=borisp@nvidia.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=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.