On Wed, Dec 22, 2021 at 04:45:52PM -0600, Eric Biggers wrote: > > Some of the LTP tests check for ENOENT to determine whether an algorithm is > intentionally unavailable, as opposed to it failing due to some other error. > There is code in the kernel that does this same check too, e.g. > fs/crypto/keysetup.c and block/blk-crypto-fallback.c. > > The way that ELIBBAD is overloaded to mean essentially the same thing as ENOENT, > but only in some cases, is not expected. > > It would be more logical for ELIBBAD to be restricted to actual test failures. > > If it is too late to change, then fine, but it seems like a bug to me. For the purpose of identifying FIPS-disabled algorithm (as opposed to an algorithm that's not enabled in the kernel at all), I think it is perfectly safe to use ELIBBAD instead of ENOENT in user-space. Remember that ELIBBAD means that every kernel implementation of the given algorithm has failed. Since we would never allow a generic algorithm to be merged into the kernel unless it passed its own self-test, this is extremely unlikely unless the algorithm has been disabled by FIPS. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
