Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c9b6787ba9154d1f4c2bf25387a35453ad20badb.camel@kernel.org>
Subject: Re: [PATCH v2 00/15] RPC-with-TLS client side
From:   Jeff Layton <jlayton@kernel.org>
To:     Chuck Lever <chuck.lever@oracle.com>, linux-nfs@vger.kernel.org
Cc:     trondmy@hammerspace.com
Date:   Tue, 12 Jul 2022 08:36:17 -0400
In-Reply-To: <165452664596.1496.16204212908726904739.stgit@oracle-102.nfsv4.dev>
References: <165452664596.1496.16204212908726904739.stgit@oracle-102.nfsv4.dev>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.3 (3.44.3-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

On Mon, 2022-06-06 at 10:50 -0400, Chuck Lever wrote:
> Now that the initial v5.19 merge window has closed, it's time for
> another round of review for RPC-with-TLS support in the Linux NFS
> client. This is just the RPC-specific portions. The full series is
> available in the "topic-rpc-with-tls-upcall" branch here:
>=20
> https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git
>=20
> I've taken two or three steps towards implementing the architecture
> Trond requested during the last review. There is now a two-stage
> connection establishment process so that the upper level can use
> XPRT_CONNECTED to determine when a TLS session is ready to use.
> There are probably additional changes and simplifications that can
> be made. Please review and provide feedback.
>=20
> I wanted to make more progress on client-side authentication (ie,
> passing an x.509 cert from the client to the server) but NFSD bugs
> have taken all my time for the past few weeks.
>=20
>=20
> Changes since v1:
> - Rebased on v5.18
> - Re-ordered so generic fixes come first
> - Addressed some of Trond's review comments
>=20
> ---
>=20
> Chuck Lever (15):
>       SUNRPC: Fail faster on bad verifier
>       SUNRPC: Widen rpc_task::tk_flags
>       SUNRPC: Replace dprintk() call site in xs_data_ready
>       NFS: Replace fs_context-related dprintk() call sites with tracepoin=
ts
>       SUNRPC: Plumb an API for setting transport layer security
>       SUNRPC: Trace the rpc_create_args
>       SUNRPC: Refactor rpc_call_null_helper()
>       SUNRPC: Add RPC client support for the RPC_AUTH_TLS auth flavor
>       SUNRPC: Ignore data_ready callbacks during TLS handshakes
>       SUNRPC: Capture cmsg metadata on client-side receive
>       SUNRPC: Add a connect worker function for TLS
>       SUNRPC: Add RPC-with-TLS support to xprtsock.c
>       SUNRPC: Add RPC-with-TLS tracepoints
>       NFS: Have struct nfs_client carry a TLS policy field
>       NFS: Add an "xprtsec=3D" NFS mount option
>=20
>=20
>  fs/nfs/client.c                 |  14 ++
>  fs/nfs/fs_context.c             |  65 +++++--
>  fs/nfs/internal.h               |   2 +
>  fs/nfs/nfs3client.c             |   1 +
>  fs/nfs/nfs4client.c             |  16 +-
>  fs/nfs/nfstrace.h               |  77 ++++++++
>  fs/nfs/super.c                  |   7 +
>  include/linux/nfs_fs_sb.h       |   5 +-
>  include/linux/sunrpc/auth.h     |   1 +
>  include/linux/sunrpc/clnt.h     |  15 +-
>  include/linux/sunrpc/sched.h    |  32 ++--
>  include/linux/sunrpc/xprt.h     |   2 +
>  include/linux/sunrpc/xprtsock.h |   4 +
>  include/net/tls.h               |   2 +
>  include/trace/events/sunrpc.h   | 157 ++++++++++++++--
>  net/sunrpc/Makefile             |   2 +-
>  net/sunrpc/auth.c               |   2 +-
>  net/sunrpc/auth_tls.c           | 120 +++++++++++++
>  net/sunrpc/clnt.c               |  34 ++--
>  net/sunrpc/debugfs.c            |   2 +-
>  net/sunrpc/xprtsock.c           | 310 +++++++++++++++++++++++++++++++-
>  21 files changed, 805 insertions(+), 65 deletions(-)
>  create mode 100644 net/sunrpc/auth_tls.c
>=20
> --
> Chuck Lever
>=20

Chuck,

How have you been testing this series? It looks like nfsd support is not
fully in yet, so I was wondering if you had a 3rd party server. I'd like
to do a little testing with this, and was wondering what I needed to
cobble together a test rig.

Thanks,
--=20
Jeff Layton <jlayton@kernel.org>