On Thu, Dec 23, 2021 at 09:21:13AM +0100, Petr Vorel wrote: > Hi Herbert, Eric, > > [ Cc Cyril ] > > > On Thu, Dec 23, 2021 at 09:31:33AM +1100, Herbert Xu wrote: > > > On Wed, Dec 22, 2021 at 04:25:07PM -0600, Eric Biggers wrote: > > > > > Isn't it just an implementation detail that !fips_allowed is handled by the > > > > self-test? Wouldn't it make more sense to report ENOENT for such algorithms? > > > > ELIBBAD does not necessarily mean !fips_allowed, it could also > > > mean a specific implementation (or hardware) failed the self-test. > Herbert, Thanks for confirmation this was intended. > > > > Yes, we could change ELIBBAD to something else in the case of > > > !fips_allowed, but it's certainly not a trivial change. > > > > Please give a motivation for this. > > > > Thanks, > > > 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. > > Not sure if it's a bug or not. With ENOENT everybody would understand missing > algorithm (no fix needed in the software). OTOH ELIBBAD allow to distinguish the > reason (algorithm was there, but disabled). Being able to distinguish between those reasons doesn't seem to be important, whereas being able to distinguish between a self-test failure and an algorithm being disabled is important. - Eric
