Re: ELIBBAD vs. ENOENT for ciphers not allowed by FIPS

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 [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt