All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
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 14:08:51 -0700	[thread overview]
Message-ID: <20220428140851.6e9eebd5@kernel.org> (raw)
In-Reply-To: <F64C2771-663D-4BE7-9EB9-A8859818C7F8@oracle.com>

On Thu, 28 Apr 2022 01:29:10 +0000 Chuck Lever III wrote:
> > 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 

Actually - is that strictly necessary? It seems reasonable for NFS to
check that it got TLS, since that's what it explicitly asks for per
standard. But it may not always be the goal. In large data center
networks there can be a policy the user space agent consults to choose
what security to install. It may end up doing the auth but not enable
crypto if confidentiality is deemed unnecessary.

Obviously you may not have those requirements but if we can cover them
without extra complexity it'd be great.

> whether the IV implantation was successful.

I'm used to IV meaning Initialization Vector in context of crypto,
what does "IV implementation" stand for?

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

recv()-based version would certainly make me happy.

  reply	other threads:[~2022-04-28 21:08 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
2022-04-28 21:08                   ` Jakub Kicinski [this message]
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=20220428140851.6e9eebd5@kernel.org \
    --to=kuba@kernel.org \
    --cc=ak@tempesta-tech.com \
    --cc=borisp@nvidia.com \
    --cc=chuck.lever@oracle.com \
    --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.