ELIBBAD vs. ENOENT for ciphers not allowed by FIPS

ELIBBAD vs. ENOENT for ciphers not allowed by FIPS

[Petr Vorel]

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?

Kind regards,
Petr

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

[Herbert Xu]

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Eric Biggers]

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

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

[Herbert Xu]

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Eric Biggers]

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

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

[Petr Vorel]

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

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

[Eric Biggers]

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

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

[Herbert Xu]

On Thu, Dec 23, 2021 at 09:08:46AM -0600, Eric Biggers wrote:
> 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.

ELIBBAD isn't equivalent to a self-test failure at all.  ELIBBAD
means that every implementation of an algorithm that the kernel
could find has failed the self-test.

If one implementation fails the self-test while other implementations
(such as the generic one) of the same algorithm still exist, the
kernel would never return ELIBBAD.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Herbert Xu]

On Wed, Dec 22, 2021 at 04:45:52PM -0600, Eric Biggers wrote:
>
> 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.

For the purpose of identifying FIPS-disabled algorithm (as opposed
to an algorithm that's not enabled in the kernel at all), I think
it is perfectly safe to use ELIBBAD instead of ENOENT in user-space.

Remember that ELIBBAD means that every kernel implementation of
the given algorithm has failed.  Since we would never allow a
generic algorithm to be merged into the kernel unless it passed
its own self-test, this is extremely unlikely unless the algorithm
has been disabled by FIPS.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt