Date:   Wed, 22 Dec 2021 16:25:07 -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: <YcOlw1UJizlngAEG@quark>
References: <YcN4S7NIV9F0XXPP@pevik>
 <YcOh6jij1s6KA2ee@gondor.apana.org.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YcOh6jij1s6KA2ee@gondor.apana.org.au>
Precedence: bulk

On Thu, Dec 23, 2021 at 09:08:42AM +1100, Herbert Xu wrote:
> On Wed, Dec 22, 2021 at 08:11:07PM +0100, Petr Vorel wrote:
> > Hi Herbert,
> > 
> > do I understand the crypto code correctly, that although crypto/testmgr.c in
> > alg_test() returns -EINVAL for non-fips allowed algorithms (that means
> > failing crypto API test) the API in crypto_alg_lookup() returns -ELIBBAD for
> > failed test?
> > 
> > Why ELIBBAD and not ENOENT like for missing ciphers? To distinguish between
> > missing cipher and disabled one due fips?
> 
> Correct.  ELIBBAD is returned for a failed self-test while ENOENT
> means that there is no algorithm at all.
> 
> This matters if there is more than one provider of the same algorithm.
> In that case ELIBBAD would only be returned if all failed the self-test.
> 

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?

- Eric