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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d85b364d-b7d6-4893-b0eb-3df58ef45ce0@oracle.com>
Date: Thu, 16 Oct 2025 09:41:27 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Eric Biggers <ebiggers@...nel.org>, Jeff Layton <jlayton@...nel.org>
Cc: 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/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?


-- 
Chuck Lever

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ