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

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