All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: netdev@vger.kernel.org, linux-nfs@vger.kernel.org,
	linux-nvme@lists.infradead.org, linux-cifs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Cc: ak@tempesta-tech.com, borisp@nvidia.com, simo@redhat.com
Subject: [PATCH RFC 0/5] Implement a TLS handshake upcall
Date: Mon, 18 Apr 2022 12:49:22 -0400	[thread overview]
Message-ID: <165030051838.5073.8699008789153780301.stgit@oracle-102.nfsv4.dev> (raw)

There are a few upper-layer (storage) protocols that want to have a
full TLS implementation available in the Linux kernel.

The Linux kernel currently has an implementation of the TLS record
protocol, known as kTLS. However it does not have a complete TLS
implementation because it has no implementation of the TLS handshake
protocol. In-kernel storage protocols need both to use TLS properly.

In the long run, our preference is to have a TLS handshake
implementation in the kernel. However, it appears that would take a
long time and there is some desire to avoid adding to the Linux
kernel's "attack surface" without good reasons. So in the meantime
we've created a prototype handshake implementation that calls out to
user space where the actual handshake can be done by an existing
library implementation of TLS.

The prototype serves several purposes, including:

- Proof of concept: can a handshake upcall actually be implemented?

- Scaffold to enable prototyping upper-layer protocol support for TLS:
  Is there any demand for in-kernel TLS?

- Performance impact of always-on encryption with both software and
  hardware kTLS

- Understanding what features, if any, an upcall handshake cannot
  provide

The prototype currently supports client-side PSK and anonymous
x.509 ClientHello. We would like some feedback on the approach
before proceeding with ServerHello and mutual x.509 authentication.


User agent: https://github.com/oracle/ktls-utils

Who will use this implementation?
--------------------------------

This series implements only the upcall. I plan to post a second
series that shows how it can be used to implement the RPC-with-TlS
standard: https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/

https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git topic-rpc-with-tls

Dr. Hannes Reinecke has a series that implements NVMe-TLS here:

https://git.kernel.org/pub/scm/linux/kernel/git/hare/scsi-devel.git tls-upcall.v4

We are also working with a few developers in the CIFS community
who are interested in SMB-over-QUIC. QUICv1 (RFC 9000) uses the
TLSv1.3 handshake protocol, and we hope they can leverage this
prototype capability when QUIC comes to the Linux kernel.

---

Chuck Lever (4):
      net: Add distinct sk_psock field
      net/tls: Add an AF_TLSH address family
      net/tls: Add support for PF_TLSH (a TLS handshake listener)
      net/tls: Add observability for AF_TLSH sockets

Hannes Reinecke (1):
      tls: build proto after context has been initialized


 .../networking/tls-in-kernel-handshake.rst    |  103 ++
 include/linux/skmsg.h                         |    2 +-
 include/linux/socket.h                        |    5 +-
 include/net/sock.h                            |    7 +-
 include/net/tls.h                             |   15 +
 include/net/tlsh.h                            |   22 +
 include/uapi/linux/tls.h                      |   16 +
 net/core/skmsg.c                              |    6 +-
 net/core/sock.c                               |    4 +-
 net/socket.c                                  |    1 +
 net/tls/Makefile                              |    2 +-
 net/tls/af_tlsh.c                             | 1078 +++++++++++++++++
 net/tls/tls_main.c                            |   13 +-
 net/tls/trace.c                               |    3 +
 net/tls/trace.h                               |  355 ++++++
 security/selinux/hooks.c                      |    4 +-
 security/selinux/include/classmap.h           |    4 +-
 .../perf/trace/beauty/include/linux/socket.h  |    4 +-
 18 files changed, 1631 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/networking/tls-in-kernel-handshake.rst
 create mode 100644 include/net/tlsh.h
 create mode 100644 net/tls/af_tlsh.c

--
Chuck Lever


             reply	other threads:[~2022-04-18 16:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 16:49 Chuck Lever [this message]
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
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=165030051838.5073.8699008789153780301.stgit@oracle-102.nfsv4.dev \
    --to=chuck.lever@oracle.com \
    --cc=ak@tempesta-tech.com \
    --cc=borisp@nvidia.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 \
    /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.