Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <4b688e56ae45defedb08603945741218736923c0.camel@chronox.de>
Subject: Re: [PATCH] crypto: testmgr - add NIAP FPT_TST_EXT.1 subset of tests
From:   Stephan Mueller <smueller@chronox.de>
To:     Elena Petrova <lenaptr@google.com>, linux-crypto@vger.kernel.org
Cc:     Eric Biggers <ebiggers@kernel.org>
Date:   Fri, 08 Jan 2021 19:53:36 +0100
In-Reply-To: <20210108173849.333780-1-lenaptr@google.com>
References: <20210108173849.333780-1-lenaptr@google.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.2 (3.38.2-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Am Freitag, dem 08.01.2021 um 17:38 +0000 schrieb Elena Petrova:
> NIAP FPT_TST_EXT.1 [1] specification requires testing of a small set of
> cryptographic modules on boot for devices that need to be NIAP
> compliant. This is also a requirement for FIPS CMVP 140-2/140-3
> certification.
> 
> Currently testmgr adds significant boot time overhead when enabled; we
> measured 3-5 seconds for Android.

I am not sure whether this is necessary. If you build the ciphers as modules,
you can insmod them during boot time before general user space is made
available. Once you insmoded all needed KOs, you load tcrypt to invoke them
which implies that they are verified. This approach allows user space to
determine which KOs are self-tested during boot.

This is the approach all Linux validations took in the past.

Besides, for FIPS 140-3, it is now allowed to have "lazy" self testing which
allows the self-tests to be executed before first use (just like what the
kernel testmgr already does).

Can you please help us understand why the mentioned approach is not
sufficient?

Thanks
Stephan