From: Jeff Layton <jlayton@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>,
NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nfsd: Use MD5 library instead of crypto_shash
Date: Sun, 12 Oct 2025 14:49:40 -0400 [thread overview]
Message-ID: <c5b9cc7300f88e4f6fbd3f0c07dd5dfa4cbaf38e.camel@kernel.org> (raw)
In-Reply-To: <20251012170018.GA1609@sol>
On Sun, 2025-10-12 at 10:00 -0700, Eric Biggers wrote:
> On Sun, Oct 12, 2025 at 07:12:26AM -0400, Jeff Layton wrote:
> > On Sat, 2025-10-11 at 11:52 -0700, Eric Biggers wrote:
> > > Update NFSD's support for "legacy client tracking" (which uses MD5) to
> > > use the MD5 library instead of crypto_shash. This has several benefits:
> > >
> > > - Simpler code. Notably, much of the error-handling code is no longer
> > > needed, since the library functions can't fail.
> > >
> > > - Improved performance due to reduced overhead. A microbenchmark of
> > > nfs4_make_rec_clidname() shows a speedup from 1455 cycles to 425.
> > >
> > > - The MD5 code can now safely be built as a loadable module when nfsd is
> > > built as a loadable module. (Previously, nfsd forced the MD5 code to
> > > built-in, presumably to work around the unreliablity of the name-based
> > > loading.) Thus, select MD5 from the tristate option NFSD if
> > > NFSD_LEGACY_CLIENT_TRACKING, instead of from the bool option NFSD_V4.
> > >
> > > To preserve the existing behavior of legacy client tracking support
> > > being disabled when the kernel is booted with "fips=1", make
> > > nfsd4_legacy_tracking_init() return an error if fips_enabled. I don't
> > > know if this is truly needed, but it preserves the existing behavior.
> > >
> >
> > FIPS is pretty draconian about algorithms, AIUI. We're not using MD5 in
> > a cryptographically significant way here, but the FIPS gods won't bless
> > a kernel that uses MD5 at all, so I think it is needed.
>
> If it's not being used for a security purpose, then I think you can just
> drop the fips_enabled check. People are used to the old API where MD5
> was always forbidden when fips_enabled, but it doesn't actually need to
> be that strict. For this patch I wasn't certain about the use case
> though, so I just opted to preserve the existing behavior for now. A
> follow-on patch to remove the check could make sense.
>
This is all legacy code anyway. We just recently flipped the default
for CONFIG_NFSD_LEGACY_CLIENT_TRACKING to 'n', so I'm hoping that in a
year or so we should be able to just remove it altogether.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-10-12 18:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 18:52 [PATCH] nfsd: Use MD5 library instead of crypto_shash Eric Biggers
2025-10-12 11:12 ` Jeff Layton
2025-10-12 17:00 ` Eric Biggers
2025-10-12 17:57 ` Simo Sorce
2025-10-12 18:49 ` Jeff Layton [this message]
2025-10-16 13:41 ` Chuck Lever
2025-10-16 18:07 ` Eric Biggers
2025-10-16 18:12 ` Chuck Lever
2025-10-12 15:59 ` Chuck Lever
2025-10-13 10:46 ` Scott Mayhew
2025-10-13 13:32 ` Chuck Lever
2025-10-14 7:56 ` Ard Biesheuvel
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=c5b9cc7300f88e4f6fbd3f0c07dd5dfa4cbaf38e.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=ebiggers@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox