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

[Eric Biggers <ebiggers@kernel.org>]

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