linux-kernel - Re: [PATCH] nfsd: Use MD5 library instead of crypto

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3d9a347d-4929-4d78-936b-30f55fe65d18@oracle.com>
Date: Thu, 16 Oct 2025 14:12:32 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Jeff Layton <jlayton@...nel.org>, linux-nfs@...r.kernel.org,
        NeilBrown <neil@...wn.name>, Olga Kornievskaia <okorniev@...hat.com>,
        Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nfsd: Use MD5 library instead of crypto_shash

On 10/16/25 2:07 PM, Eric Biggers wrote:
> On Thu, Oct 16, 2025 at 09:41:27AM -0400, Chuck Lever wrote:
>> On 10/12/25 1:00 PM, 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.
>> Eric, were you going to follow up with a fresh revision that drops the
>> fips_enabled check?
> 
> Sure, if you want.  I see you're also planning to revert my prerequisite
> patch "SUNRPC: Make RPCSEC_GSS_KRB5 select CRYPTO instead of depending
> on it".  So I also need to work around that by keeping the
> 'select CRYPTO' in NFSD_V4.

Or we can wait until either that patch is merged again, or the legacy
NFS client tracking implementation is finally removed. Let me know your
timing requirements.


-- 
Chuck Lever