This is needed to meet a FIPS 140-3 requirement that modules provide a
service that retrieves their name and versioning information.
Bug: 188620248
Change-Id: I36049c839c4217e3616daab52ec536b46479c12a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2888f960d09f3af00d1e45f1facd311ccd5b778a)
To satisfy the FIPS 140-3 "service indicators" requirement, add a
function which checks whether the given algorithm is "approved" or not.
Note that this function is a bit different from the module's other APIs
in that it is an exported symbol rather than a registration-based API.
This avoids needing to make kernel/KMI changes, so I think we should do
it this way if possible, given that it's unlikely this function will be
used in practice outside of the lab test. Built-in code can still call
this function via symbol_get() if it really wants to.
Bug: 188620248
Change-Id: I26c976258fa9446b34eb189bba7154142d85da16
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fe4b8d3c687efcf27064e472730291edbd81dad6)
FIPS 140-3 requires this for some reason.
Bug: 188620248
Change-Id: I7c286532097e1d8971faf4d8be31b801f9007e3b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit c14d52059bd86d27ce3c8e581196b011d0cc4d32)
The lab has confirmed that it is actually fine for users to keep using
non-FIPS code after the module has loaded if they were already using it
beforehand. So remove the code that tried to prevent this by updating
live algorithms in-place. Similarly, remove the call to
synchronize_rcu_tasks() which no longer has any purpose.
We still need to move the live algorithms to a private list, so keep
doing that. Keep appending "+orig" to cra_name as well, and start doing
the same for cra_driver_name too.
Bug: 188620248
Change-Id: I29c9faec7d7314484a03f9729924b2f892552c7c
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 54aecb72dba94d1bb68844af6e4790b5823fb6ce)
As per the new guidance from the lab, the module must block crypto
operations until the tests have completed. It's unclear what this means
exactly (given that technically this is impossible), but let's make some
changes that should be enough to comply with the requirement's intent.
First, register the library functions and update the live algorithms
after the tests rather than before the tests. This is a trivial change.
Much more problematic is the fact that the algorithms are registered
with the kernel's crypto framework before the tests run, as the tests
depend on the framework. Unfortunately, the lab believes that the
kernel isn't allowed to enforce the ordering here; the module itself
must. Moreover, trying to solve this by copying the crypto API
framework into the module proved to be heavily problematic.
Thus, implement an alternate solution: make the module override the tfm
initialization function of every algorithm it registers, so that it can
wait for the tests to complete before allowing the use of any algorithm.
This is sufficient if the user makes a supported sequence of API calls.
Bug: 153614920
Bug: 188620248
Change-Id: I11ffba90c08114dda4e91c4be7ce8b608c4e14c1
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 02e48f383b2acb42c85028563cc75453842f11ce)
Instead of having a special case in the core kernel's module loader that
treats a module called 'fips140.ko' in a special way, use a host tool to
tweak the ELF metadata of this module so that the RELA data is preserved
and accessible to the module init code.
This is done in the following way:
- each RELA section that we care about (the ones for .text and .rodata
at the moment) is copied into a new section called .init.rela.<name>
with the SHF_ALLOC attribute, so that the module loader will copy it
into __init memory at load time;
- for each such section, an offset/count tuple is added as a global
variable to the module;
- the count field of those tuples is populated directly by the host tool
based on the actual size of the RELA section in question;
- the offset field is decorated with a place-relative relocation against
the start of the copied RELA section via a weak symbol reference,
which causes an entry to be emitted into the ELF symbol table;
- these ELF symbol table entries are updated by the host tool and turned
into STT_SECTION type symbols with STB_GLOBAL linkage, carrying the
correct section index.
With these changes in place, the unmodified module loader will load all
required information into memory in a way that permits the module init
code to locate the relocations, and apply them in reverse.
Bug: 153614920
Bug: 188620248
Change-Id: I07d9704febdf913834502dd09c19aa4a04d983b1
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 502af6e3490d3ed51cf2131306303445b0d56579)
Unfortunately, the AES-GCM implementations won't actually be able to be
FIPS-approved. One consequence of this is that the "cmac" template will
need to be tested with all underlying "aes" implementations, as the
equivalent test with "gcm" won't count as fulfilling the requirement to
test all AES implementations in an authenticated mode when supported.
Update the self-tests and comments accordingly.
Bug: 153614920
Bug: 188620248
Change-Id: I874b0718a5ff9d4e2dea2353448266e87f3f0d0b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit a9765fb6dc441dff749b1120ce13180c5561f69e)
Although jitterentropy doesn't necessarily need to be part of
fips140.ko, it does need to have the SP800-90B health tests enabled, and
that requires that it be compiled with the fips_enabled flag set. The
easiest way to do this is just to include a copy of it in fips140.ko.
Bug: 153614920
Bug: 188620248
Change-Id: I9dc0281e07e08e0650e3d340897c697722ad3b1a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit cae242110570eb204b1a332b717aaa35eb16647d)
AES-CMAC is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cmac" template. Add the "cmac" template
to fips140.ko too and add a self-test for AES-CMAC, so that we can
include AES-CMAC in the set of algorithms which will be certified.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms.
Bug: 153614920
Bug: 188620248
Change-Id: I6c1d9281fe848a7101d5ef94ab48e5a41bbcc6f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 038dc9f2cc956cab561bd9d50120920010867b75)
AES-CBC-CTS is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cts" template. Add the "cts" template
to fips140.ko too and add a self-test for AES-CBC-CTS, so that we can
include AES-CBC-CTS in the set of algorithms which will be certified.
There appears to be no support for CBC-CTS mode in pycryptodome or
python-cryptography, so I manually added the test vector.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms. Android uses AES-CBC-CTS for filenames
encryption, which may be relevant (though arguably this use case doesn't
actually require a FIPS approved algorithm).
Bug: 153614920
Bug: 188620248
Change-Id: I53ffbd1d38493592eeaf471bc0007978ec400878
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit e2cfdfbc51b442a9ca96d5fad8060fb02a364eb4)
Add some help text for CONFIG_CRYPTO_FIPS140_MOD, add a comment for
CONFIG_CRYPTO_FIPS140, and update the file comment for fips140-module.c.
In particular, mention that the module also does self-tests, and that it
is also intended to meet NIAP requirements -- not just FIPS.
Bug: 153614920
Bug: 188620248
Change-Id: If2c316e54fba2c4594e70a14a5a8fa1dba3589a1
Signed-off-by: Eric Biggers <ebiggers@google.com>
Make fips140.ko run a suite of known answer self-tests at load time to
demonstrate the correct operation of cryptographic functionality, as
required by FIPS 140-2/3 and NIAP FPT_TST_EXT.1.1.
Bug: 153614920
Bug: 173104584
Bug: 188620248
Test: Built and loaded fips140.ko on a HiKey960, and on a Pixel device.
Change-Id: I38e5c8052ff57ddfe44624beb626d38b7706b0a4
Co-developed-by: Elena Petrova <lenaptr@google.com>
Signed-off-by: Elena Petrova <lenaptr@google.com>
[ebiggers: Rewrote most of lenaptr@'s original patch. Added some
missing tests, removed some unnecessary tests in accordance with the
FIPS 140-2 IG, changed most test vectors and added a script to generate
them, removed an unnecessary kconfig option, changed implementation of
error injection, and many other improvements.]
Signed-off-by: Eric Biggers <ebiggers@google.com>
[ardb: add generation of AES-CTR test vector and the associated runtime
selftest]
Signed-off-by: Ard Biesheuvel <ardb@google.com>
fips140_algorithms[] is a list of cra_names rather than
cra_driver_names, so to specify that the existing DRBG algorithms need
to be unregistered it needs to contain "stdrng".
Bug: 153614920
Bug: 188620248
Change-Id: Id655e74858ca6bff4eedaf761d54c3ae54c2260f
Signed-off-by: Eric Biggers <ebiggers@google.com>
crypto_remove_final() calls crypto_alg_put() which can take
crypto_alg_sem again, via a call stack like:
down_write(&crypto_alg_sem)
crypto_drop_spawn()
crypto_ccm_free()
crypto_aead_free_instance()
crypto_destroy_instance()
crypto_alg_put() (inlined)
crypto_remove_final()
unregister_existing_fips140_algos()
That causes a deadlock because unregister_existing_fips140_algos() is
already holding crypto_alg_sem.
Fix this by reducing the scope of crypto_alg_sem to the actual list
traversal and not the crypto_alg_put().
Bug: 153614920
Bug: 188620248
Change-Id: Ia724d8b13480233dad051c538dc504cb27be8777
Signed-off-by: Eric Biggers <ebiggers@google.com>
Check for errors when executing the initcalls so that we can't fail to
register some algorithms without noticing.
Bug: 153614920
Bug: 188620248
Change-Id: I8e55de3d7624c6700f161c92705d0f6f874476d8
Signed-off-by: Eric Biggers <ebiggers@google.com>
It may be helpful to know whether the "already-live algorithms" code
path is being executed or not, and if so, with which algorithms. Add a
log message for it.
Bug: 153614920
Bug: 188620248
Change-Id: Ie3757794b1e43f630d5dc8f888c6ad33acacbc4c
Signed-off-by: Eric Biggers <ebiggers@google.com>
Downgrade some expected log messages from pr_warn() to pr_info().
Also remove "FIPS 140" from some log messages since the messages are
already prefixed with "fips140: " (the name of the module) which makes
it redundant.
Bug: 153614920
Bug: 188620248
Change-Id: I94055d7a5a86a770fcf38e958e7d7497b4bafdf0
Signed-off-by: Eric Biggers <ebiggers@google.com>
Avoid a compiler warning about there being no previous declaration for
fips140_init().
Bug: 153614920
Bug: 188620248
Change-Id: I8192c597d16ff6f43a0e9cb45a89969666b3875e
Signed-off-by: Eric Biggers <ebiggers@google.com>
In order to comply with FIPS 140-2 requirements, implement a fips140
module that carries all AES, SHA-xxx and DRBG implementations with the
associated chaining mode templates, and perform an integrity selfcheck
at load time. The algorithms contained in the module will be registered
with the crypto API, and will supersede any existing copies of the same
algorithms that were already being provided by the core kernel.
Bug: 153614920
Bug: 188620248
Test: boot tested on Pixel hw both with and without a live algo ('hmac(sha1-ce)')
Change-Id: Ia893d9992fc12e2617d1ed2899c9794859c389d1
Signed-off-by: Ard Biesheuvel <ardb@google.com>
