Date:   Wed, 22 Dec 2021 16:45:52 -0600
From:   Eric Biggers <ebiggers@kernel.org>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Petr Vorel <pvorel@suse.cz>, linux-crypto@vger.kernel.org
Subject: Re: ELIBBAD vs. ENOENT for ciphers not allowed by FIPS
Message-ID: <YcOqoGOLfNTZh/ZF@quark>
References: <YcN4S7NIV9F0XXPP@pevik>
 <YcOh6jij1s6KA2ee@gondor.apana.org.au>
 <YcOlw1UJizlngAEG@quark>
 <YcOnRRRYbV/MrRhO@gondor.apana.org.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YcOnRRRYbV/MrRhO@gondor.apana.org.au>
Precedence: bulk

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

- Eric