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

[Petr Vorel <pvorel@suse.cz>]

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).

Kind regards,
Petr

> - Eric