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>
We currently only emit directives for handling the .text section into
the module linker script if both LTO and CFI are enabled, while for
other sections, we do this even if CFI is not enabled. This is
inconsistent at best, but as it also interferes with the assumption in
the fips140.ko module that the .text._start and .text._end input
sections are placed at the very start and end of the .text section,
which currently can only be relied upon if CFI is enabled.
So rearrange the #ifdef so that it only covers the .text.__cfi_check
input section. Note that aligning to page size is likely to be redundant
in any case, given that the .text section is laid out first, and module
allocations are page aligned to begin with, so making that part
unconditional is unlikely to make an observeable difference in the
output.
Bug: 153614920
Bug: 188620248
Fixes: 6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
Change-Id: I3f9ed0ae8fa8fe5693c8d2964566cbb42c101aa7
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 6ae8277450ae86113cf7eea8b8348e509e2cc72d)
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>
Merge module sections only when using Clang LTO. With ld.bfd, merging
sections does not appear to update the symbol tables for the module,
e.g. 'readelf -s' shows the value that a symbol would have had, if
sections were not merged. ld.lld does not show this problem.
The stale symbol table breaks gdb's function disassembler, and presumably
other things, e.g.
gdb -batch -ex "file arch/x86/kvm/kvm.ko" -ex "disassemble kvm_init"
reads the wrong bytes and dumps garbage.
Fixes: dd2776222abb ("kbuild: lto: merge module sections")
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210322234438.502582-1-seanjc@google.com
(cherry picked from commit 6a3193cdd5e5b96ac65f04ee42555c216da332af)
Bug: 187129171
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: I295d9a6b71a41fd1585059d0f48a2a2c13eb2361
With CONFIG_LTO_CLANG_FULL, LLVM drops all CFI jump table symbols
from vmlinux, which doesn't affect kernel functionality, but can
make stack traces and other kernel output that prints out jump
table addresses harder to read.
This change works around the issue for now by adding a script that
tells kallsyms about the missing jump table symbols, even though
they don't actually exist in the symbol table, and generates a
linker script to add the missing symbols to kernel modules.
Bug: 186152035
Bug: 187415564
Change-Id: Ic3c51751c756f2f5fb2a31229e16c3397eb6e666
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
On modules with no executable code, LLVM generates a __cfi_check stub,
but won't align it to page size as expected. This change ensures the
function is at the beginning of the .text section and correctly aligned
for the CFI shadow.
Also discard the .eh_frame section, which LLD may emit with CFI_CLANG.
Bug: 145210207
Change-Id: I08923febb549aa64454282cc864ac80dadd717b9
Link: https://bugs.llvm.org/show_bug.cgi?id=46293
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
The difference between vmlinux.lds and module.lds is that the latter
is needed for external module builds, thus must be cleaned up by
'make mrproper' instead of 'make clean'. Also, it must be created
by 'make modules_prepare'.
You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
scripts/module.lds.S.
scripts/module.lds is fine because 'make clean' keeps all the
build artifacts under scripts/.
You can add arch-specific sections in <asm/module.lds.h>.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Jessica Yu <jeyu@kernel.org>
