Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Stephan Mueller <smueller@chronox.de>
To:     Eric Biggers <ebiggers@kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Robert Elliott <elliott@hpe.com>, tim.c.chen@linux.intel.com,
        davem@davemloft.net, linux-crypto@vger.kernel.org,
        toshi.kani@hpe.com, rwright@hpe.com
Subject: Re: [PATCH] crypto: testmgr - don't generate WARN for missing modules
Date:   Tue, 16 Aug 2022 07:09:44 +0200
Message-ID: <2802022.gAprrWTQMp@tauon.chronox.de>
In-Reply-To: <YvsEN+6k4lTvXY7I@gondor.apana.org.au>
References: <20220813231443.2706-1-elliott@hpe.com> <Yvq65Xd6GjeLdmO5@sol.localdomain> <YvsEN+6k4lTvXY7I@gondor.apana.org.au>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

Am Dienstag, 16. August 2022, 04:43:03 CEST schrieb Herbert Xu:

Hi Herbert,

> On Mon, Aug 15, 2022 at 02:30:13PM -0700, Eric Biggers wrote:
> > Note that this is only a problem because tcrypt calls alg_test() directly.
> >  The normal way that alg_test() gets called is for the registration-time
> > self-test. It's not clear to me why tcrypt calls alg_test() directly; the
> > registration-time test should be enough.  Herbert, do you know?
> 
> The tcrypt code predates testmgr.  So at the beginning we only had
> the enumerative testing.  Registration-time testing was added later.
> 
> We could remove the enumerative testing, but I think the FIPS people
> have grown rather attached to it because it ticks some sort of a box
> at boot-time.
> 
> Stephane, would it be a problem for FIPS if we simply got rid of the
> enumerative testing in tcrypt and instead relied on registration-time
> testing?

The tcrypt code has only one purpose for FIPS: to allocate all crypto 
algorithms at boot time and thus to trigger the self test during boot time. 
That was a requirement until some time ago. These requirements were relaxed a 
bit such that a self test before first use is permitted, i.e. the approach we 
have in testmgr.c.

Therefore, presently we do not need this boot-time allocation of an algorithm 
via tcrypt which means that from a FIPS perspective tcrypt is no longer 
required.
> 
> Cheers,


Ciao
Stephan