All of lore.kernel.org
 help / color / mirror / Atom feed
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
Date: Wed, 22 Dec 2021 16:25:07 -0600	[thread overview]
Message-ID: <YcOlw1UJizlngAEG@quark> (raw)
In-Reply-To: <YcOh6jij1s6KA2ee@gondor.apana.org.au>

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

  reply	other threads:[~2021-12-22 22:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22 19:11 ELIBBAD vs. ENOENT for ciphers not allowed by FIPS Petr Vorel
2021-12-22 22:08 ` Herbert Xu
2021-12-22 22:25   ` Eric Biggers [this message]
2021-12-22 22:31     ` Herbert Xu
2021-12-22 22:45       ` Eric Biggers
2021-12-23  8:21         ` Petr Vorel
2021-12-23 15:08           ` Eric Biggers
2021-12-27  5:52             ` Herbert Xu
2021-12-27  5:51         ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YcOlw1UJizlngAEG@quark \
    --to=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=pvorel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.