From: Hannes Reinecke <hare@suse.de>
To: Jarkko Sakkinen <jarkko@kernel.org>, 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 16:46:43 +0200 [thread overview]
Message-ID: <cd2444ca-3d92-4c4e-a93c-ed2bfc4d18d5@suse.de> (raw)
In-Reply-To: <aCXjaDas4aJkoS7-@kernel.org>
On 5/15/25 14:51, Jarkko Sakkinen wrote:
> 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())?
>
With this patch the keyring is pretty much immaterial; the interface
is passing in a serial number which is unique across all keyrings.
Where the keyring comes in when looking up keys on the TLS server,
as there the TLS client hello only transports the key description
(which are not required to be unique across all keyrings).
So there we'll need the keyring to be specified.
But for the client we really don't.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2025-05-15 14:46 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
2025-05-15 14:46 ` Hannes Reinecke [this message]
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=cd2444ca-3d92-4c4e-a93c-ed2bfc4d18d5@suse.de \
--to=hare@suse.de \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dhowells@redhat.com \
--cc=hch@lst.de \
--cc=jarkko@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).