Add a new fips140_lab_util command 'show_invalid_inputs' which uses
AF_ALG to call some crypto algorithms with invalid parameters to show
that they fail. This is needed to meet a new requirement we've received
from the lab. This requirement is vague, but a representative sample of
algorithms and inputs appears to be acceptable.
For this to work, AF_ALG needs to be enabled in the kernel. This makes
fips140_lab_util start depending on a custom kernel build, not just on a
custom fips140 module build as was the case before. However, the lab
testing was going to need custom boot images anyway once fips140.ko is
included in the normal builds, since the production build of fips140.ko
won't have CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING=y. AF_ALG is also
needed to do the Jitter RNG entropy analysis properly, and the
AF_ALG-enabled kernel can also be reused for ACVP testing.
Bug: 188620248
Change-Id: I69054eab5005fc3ca0ea081760877f73ea229f5b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 04e49b41be57bbc668e39a2bb65fa6022a22deba)
fips140_lab_test doesn't really do any tests per se, but rather is a
utility program that dumps some output. The actual "test" is when the
lab checks the output; we aren't allowed to check it ourselves.
We also need to add some new functionality, which would work well as
sub-commands. Also, the original idea was that this was just sample
code which the lab would modify, but that's not actually happening.
Therefore, rename fips140_lab_test to fips140_lab_util, and refactor its
functionality into sub-commands 'show_module_version' and
'show_service_indicators'. This fits better with what is needed.
Bug: 188620248
Change-Id: I7da84a139283f185f79b8d866547151169f26415
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 6ed33b82eaf8352574ba9ac7cff351a678fbe8e6)
The FIPS lab is required to test the service indicators and version
information services of the module, i.e. the
fips140_is_approved_service() and fips140_module_version() functions.
There are several ways we could support this:
- Implement the tests in the module ourselves. However it's unclear
that CMVP would allow this, and we would need the full list of tests,
which could change over time depending on what the lab decides to do.
- Support the lab writing, building, and loading a custom kernel module
(or a custom kernel image) that tests these functions.
- Provide a userspace interface to these services, restricted to builds
with CONFIG_CRYPTO_FIPS140_MOD_EVAL_TESTING=y. This would allow
writing the tests in userspace, which would be much easier.
Implement the last solution, since it's the easier of the two solutions
that are "guaranteed" to be allowed. Make the module register a char
device which supports some ioctls, one per function that needs to be
tested. Also provide some sample userspace code in samples/crypto/.
Note: copy_to_user() would break the integrity check, so take some care
to exclude it. This is allowed since this is non-production code.
Bug: 188620248
Change-Id: Ic256d9c5bd4d0c57ede88a3e3e76e89554909b38
Signed-off-by: Eric Biggers <ebiggers@google.com>
