From: Jarkko Sakkinen <jarkko@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chuck Lever <chuck.lever@oracle.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
David Howells <dhowells@redhat.com>,
linux-nfs@vger.kernel.org,
kernel-tls-handshake <kernel-tls-handshake@lists.linux.dev>,
keyrings@vger.kernel.org
Subject: Re: [PATCH 1/2] NFS: support the kernel keyring for TLS
Date: Thu, 15 May 2025 15:51:52 +0300 [thread overview]
Message-ID: <aCXjaDas4aJkoS7-@kernel.org> (raw)
In-Reply-To: <20250515115107.33052-2-hch@lst.de>
On Thu, May 15, 2025 at 01:50:55PM +0200, Christoph Hellwig wrote:
> Allow tlshd to use a per-mount key from the kernel keyring similar
> to NVMe over TCP.
>
> Note that tlshd expects keys and certificates stored in the kernel
> keyring to be in DER format, not the PEM format used for file based keys
> and certificates, so they need to be converted before they are added
> to the keyring, which is a bit unexpected.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/nfs/fs_context.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c
> index 13f71ca8c974..9e94d18448ff 100644
> --- a/fs/nfs/fs_context.c
> +++ b/fs/nfs/fs_context.c
> @@ -96,6 +96,8 @@ enum nfs_param {
> Opt_wsize,
> Opt_write,
> Opt_xprtsec,
> + Opt_cert_serial,
> + Opt_privkey_serial,
> };
>
> enum {
> @@ -221,6 +223,8 @@ static const struct fs_parameter_spec nfs_fs_parameters[] = {
> fsparam_enum ("write", Opt_write, nfs_param_enums_write),
> fsparam_u32 ("wsize", Opt_wsize),
> fsparam_string("xprtsec", Opt_xprtsec),
> + fsparam_s32("cert_serial", Opt_cert_serial),
> + fsparam_s32("privkey_serial", Opt_privkey_serial),
> {}
> };
>
> @@ -551,6 +555,32 @@ static int nfs_parse_version_string(struct fs_context *fc,
> return 0;
> }
>
> +#ifdef CONFIG_KEYS
> +static int nfs_tls_key_verify(key_serial_t key_id)
> +{
> + struct key *key = key_lookup(key_id);
> + int error = 0;
> +
> + if (IS_ERR(key)) {
> + pr_err("key id %08x not found\n", key_id);
> + return PTR_ERR(key);
> + }
> + if (test_bit(KEY_FLAG_REVOKED, &key->flags) ||
> + test_bit(KEY_FLAG_INVALIDATED, &key->flags)) {
> + pr_err("key id %08x revoked\n", key_id);
> + error = -EKEYREVOKED;
> + }
> +
> + key_put(key);
> + return error;
> +}
This is equivalent nvme_tls_key_lookup() so would it be more senseful
to call it nfs_tls_key_lookup()? I'm also a bit puzzled how the code
will associate nfs_keyring to all this (e.g., with keyring_search as
done in nvme_tls_psk_lookup())?
> +#else
> +static inline int nfs_tls_key_verify(key_serial_t key_id)
> +{
> + return -ENOENT;
> +}
> +#endif /* CONFIG_KEYS */
> +
> /*
> * Parse a single mount parameter.
> */
> @@ -807,6 +837,18 @@ static int nfs_fs_context_parse_param(struct fs_context *fc,
> if (ret < 0)
> return ret;
> break;
> + case Opt_cert_serial:
> + ret = nfs_tls_key_verify(result.int_32);
> + if (ret < 0)
> + return ret;
> + ctx->xprtsec.cert_serial = result.int_32;
> + break;
> + case Opt_privkey_serial:
> + ret = nfs_tls_key_verify(result.int_32);
> + if (ret < 0)
> + return ret;
> + ctx->xprtsec.privkey_serial = result.int_32;
> + break;
>
> case Opt_proto:
> if (!param->string)
> --
> 2.47.2
>
I get the change i.e., keep keys opaque, and it is a reasonable goal.
However, the keyring-key association is where I get lost, so if you
could help me out with that a bit, we could make progress :-)
BR, Jarkko
next prev parent reply other threads:[~2025-05-15 12:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 11:50 support keyrings for NFS TLS mounts v2 Christoph Hellwig
2025-05-15 11:50 ` [PATCH 1/2] NFS: support the kernel keyring for TLS Christoph Hellwig
2025-05-15 12:51 ` Jarkko Sakkinen [this message]
2025-05-15 14:46 ` Hannes Reinecke
2025-05-16 5:17 ` Christoph Hellwig
2025-05-16 17:01 ` Jarkko Sakkinen
2025-05-16 11:47 ` Sagi Grimberg
2025-05-15 11:50 ` [PATCH 2/2] nfs: create a kernel keyring Christoph Hellwig
2025-05-16 11:47 ` Sagi Grimberg
2025-05-16 17:03 ` Jarkko Sakkinen
2025-05-17 9:45 ` Sagi Grimberg
2025-06-02 15:25 ` Christoph Hellwig
2025-06-04 16:42 ` Jarkko Sakkinen
2025-06-05 4:28 ` Christoph Hellwig
2025-06-06 16:47 ` Jarkko Sakkinen
2025-06-09 4:01 ` Christoph Hellwig
2025-06-09 21:28 ` Jarkko Sakkinen
2025-06-10 4:34 ` Christoph Hellwig
2025-05-17 18:39 ` kernel test robot
2025-05-15 12:31 ` support keyrings for NFS TLS mounts v2 Chuck Lever
2025-05-16 5:16 ` Christoph Hellwig
2025-05-16 11:46 ` Sagi Grimberg
2025-07-10 7:25 ` Christoph Hellwig
2025-07-10 13:14 ` Trond Myklebust
-- strict thread matches above, loose matches on Subject: below --
2025-05-07 8:09 RFC: support keyrings for NFS TLS mounts Christoph Hellwig
2025-05-07 8:09 ` [PATCH 1/2] NFS: support the kernel keyring for TLS Christoph Hellwig
2025-05-07 14:48 ` Sagi Grimberg
2025-05-07 15:01 ` Chuck Lever
2025-05-08 8:07 ` kernel test robot
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=aCXjaDas4aJkoS7-@kernel.org \
--to=jarkko@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dhowells@redhat.com \
--cc=hch@lst.de \
--cc=kernel-tls-handshake@lists.linux.dev \
--cc=keyrings@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.org \
/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.