Re: nfsd needs "md5", but fips=1 disables it -> hang

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Mar 27, 2014 at 08:52:39PM +1100, NeilBrown wrote:
> 
> [I sent this 2 days ago but haven't seen it come back on the nfs
>  list and don't see it in the archives.  Maybe someone we cannot name
>  filtered it because it contains the word 'crypto' ??]

Huh.

> Apparently there is a thing called "FIPS" which lists some approved crypto
> algorithms.  And some sites need to only use those.  So they boot their
> kernel with
>     fips=1
> and anything non-fips-approved stops working.
> 
> "md5" is not fips-approved.
> 
> So
> 
> 	desc.tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
> 
> in
> 
> nfs4_make_rec_clidname(char *dname, const struct xdr_netobj *clname)
> 
> 
> always fails when fips=1.  This interferes with efficient NFS service (every
> 'open' hangs).
> 
> s/md5/sha1/
> 
> makes this problem go away, because sha1 is fips-approved.
> 
> My question is: is this safe, or is the hash value used in some external way
> (in /var/lib/nfs/v4recovery ??).

Right, it's used in v4recovery, so you'd lose client state when you
rebooted the server to the new (SHA1-using) server.

Our intention was to migrate people that care about FIPS to the umh
upcall.  But rhel6 has a hack (a private md5 implementation).

Cc'ing jlayton (currently traveling) who did that work.

--b.

> 
> If changing the hash to sha1 is safe, we should do that and probably add
>   select CRYPTO_SHA1
> to Kconfig just to be safe.
> 
> If we really need to keep it stable, I guess we need to find a way to perform
> md5 computations that bypasses the fips checks.