From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>, NeilBrown <neilb@ownmail.net>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>,
jaeyeong <fin@spl.team>,
Benjamin Coddington <bcodding@hammerspace.com>
Subject: Re: [PATCH] NFSD: Report whether fh_key was actually updated
Date: Tue, 21 Apr 2026 16:05:37 -0400 [thread overview]
Message-ID: <5e27fcbff7ff788bf750482f5fb9ad607f30ac82.camel@kernel.org> (raw)
In-Reply-To: <20260421192021.428052-1-cel@kernel.org>
On Tue, 2026-04-21 at 15:20 -0400, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> The nfsd_ctl_fh_key_set tracepoint was introduced to capture
> operator activity on the filehandle signing key. Earlier revisions
> logged the key bytes verbatim; the version that landed hashes the
> 16 key bytes through crc32_le and stores the result.
>
> CRC32 is a linear projection of its input rather than a one-way
> function, and truncating any hash of fixed-size secret material
> leaves the key recoverable under offline brute force when the
> threat model includes an attacker with access to the trace ring.
>
> The operational question the fingerprint was meant to answer is
> whether a NFSD_CMD_THREADS_SET call that carries an
> NFSD_A_SERVER_FH_KEY attribute actually replaced the active key or
> re-installed the value already in place. Answer that question
> directly: compare the incoming key bytes against the current
> nn->fh_key inside nfsd_nl_fh_key_set() and surface a single bit to
> the tracepoint. The event now prints "updated" when the stored
> key changed and "unmodified" otherwise. A first set that fails
> kmalloc reports "unmodified" because no key was installed.
>
> Reported-by: jaeyeong <fin@spl.team>
> Fixes: 62346217fd72 ("NFSD: Add a key for signing filehandles")
> Cc: Benjamin Coddington <bcodding@hammerspace.com>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> fs/nfsd/nfsctl.c | 18 ++++++++++++++----
> fs/nfsd/trace.h | 16 +++++++---------
> 2 files changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> index c76849f316f7..064a2e749bc9 100644
> --- a/fs/nfsd/nfsctl.c
> +++ b/fs/nfsd/nfsctl.c
> @@ -1610,16 +1610,27 @@ int nfsd_nl_rpc_status_get_dumpit(struct sk_buff *skb,
> static int nfsd_nl_fh_key_set(const struct nlattr *attr, struct nfsd_net *nn)
> {
> siphash_key_t *fh_key = nn->fh_key;
> + u64 k0, k1;
> + bool changed;
> +
> + k0 = get_unaligned_le64(nla_data(attr));
> + k1 = get_unaligned_le64(nla_data(attr) + 8);
>
> if (!fh_key) {
> fh_key = kmalloc(sizeof(siphash_key_t), GFP_KERNEL);
> - if (!fh_key)
> + if (!fh_key) {
> + trace_nfsd_ctl_fh_key_set(false, -ENOMEM);
> return -ENOMEM;
> + }
> nn->fh_key = fh_key;
> + changed = true;
> + } else {
> + changed = fh_key->key[0] != k0 || fh_key->key[1] != k1;
> }
>
> - fh_key->key[0] = get_unaligned_le64(nla_data(attr));
> - fh_key->key[1] = get_unaligned_le64(nla_data(attr) + 8);
> + fh_key->key[0] = k0;
> + fh_key->key[1] = k1;
> + trace_nfsd_ctl_fh_key_set(changed, 0);
> return 0;
> }
>
> @@ -1698,7 +1709,6 @@ int nfsd_nl_threads_set_doit(struct sk_buff *skb, struct genl_info *info)
> attr = info->attrs[NFSD_A_SERVER_FH_KEY];
> if (attr) {
> ret = nfsd_nl_fh_key_set(attr, nn);
> - trace_nfsd_ctl_fh_key_set((const char *)nn->fh_key, ret);
> if (ret)
> goto out_unlock;
> }
> diff --git a/fs/nfsd/trace.h b/fs/nfsd/trace.h
> index a13d18447324..1c5a1e50f946 100644
> --- a/fs/nfsd/trace.h
> +++ b/fs/nfsd/trace.h
> @@ -2263,23 +2263,21 @@ TRACE_EVENT(nfsd_end_grace,
>
> TRACE_EVENT(nfsd_ctl_fh_key_set,
> TP_PROTO(
> - const char *key,
> + bool changed,
> int result
> ),
> - TP_ARGS(key, result),
> + TP_ARGS(changed, result),
> TP_STRUCT__entry(
> - __field(u32, key_hash)
> + __field(bool, changed)
> __field(int, result)
> ),
> TP_fast_assign(
> - if (key)
> - __entry->key_hash = ~crc32_le(0xFFFFFFFF, key, 16);
> - else
> - __entry->key_hash = 0;
> + __entry->changed = changed;
> __entry->result = result;
> ),
> - TP_printk("key=0x%08x result=%d",
> - __entry->key_hash, __entry->result
> + TP_printk("key %s, result=%d",
> + __entry->changed ? "updated" : "unmodified",
> + __entry->result
> )
> );
>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2026-04-21 20:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 19:20 [PATCH] NFSD: Report whether fh_key was actually updated Chuck Lever
2026-04-21 19:51 ` Benjamin Coddington
2026-04-21 20:05 ` Jeff Layton [this message]
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=5e27fcbff7ff788bf750482f5fb9ad607f30ac82.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=bcodding@hammerspace.com \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=fin@spl.team \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@ownmail.net \
--cc=okorniev@redhat.com \
--cc=tom@talpey.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.