summaryrefslogtreecommitdiffstats
path: root/crypto/jitterentropy-kcapi.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* crypto: jitter - add interface for gathering of raw entropyStephan Müller2023-05-121-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test interface allows a privileged process to capture the raw unconditioned noise that is collected by the Jitter RNG for statistical analysis. Such testing allows the analysis how much entropy the Jitter RNG noise source provides on a given platform. The obtained data is the time stamp sampled by the Jitter RNG. Considering that the Jitter RNG inserts the delta of this time stamp compared to the immediately preceding time stamp, the obtained data needs to be post-processed accordingly to obtain the data the Jitter RNG inserts into its entropy pool. The raw entropy collection is provided to obtain the raw unmodified time stamps that are about to be added to the Jitter RNG entropy pool and are credited with entropy. Thus, this patch adds an interface which renders the Jitter RNG insecure. This patch is NOT INTENDED FOR PRODUCTION SYSTEMS, but solely for development/test systems to verify the available entropy rate. Access to the data is given through the jent_raw_hires debugfs file. The data buffer should be multiples of sizeof(u32) to fill the entire buffer. Using the option jitterentropy_testing.boot_raw_hires_test=1 the raw noise of the first 1000 entropy events since boot can be sampled. This test interface allows generating the data required for analysis whether the Jitter RNG is in compliance with SP800-90B sections 3.1.3 and 3.1.4. If the test interface is not compiled, its code is a noop which has no impact on the performance. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitter - replace LFSR with SHA3-256Stephan Müller2023-05-121-20/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the kernel crypto API, the SHA3-256 algorithm is used as conditioning element to replace the LFSR in the Jitter RNG. All other parts of the Jitter RNG are unchanged. The application and use of the SHA-3 conditioning operation is identical to the user space Jitter RNG 3.4.0 by applying the following concept: - the Jitter RNG initializes a SHA-3 state which acts as the "entropy pool" when the Jitter RNG is allocated. - When a new time delta is obtained, it is inserted into the "entropy pool" with a SHA-3 update operation. Note, this operation in most of the cases is a simple memcpy() onto the SHA-3 stack. - To cause a true SHA-3 operation for each time delta operation, a second SHA-3 operation is performed hashing Jitter RNG status information. The final message digest is also inserted into the "entropy pool" with a SHA-3 update operation. Yet, this data is not considered to provide any entropy, but it shall stir the entropy pool. - To generate a random number, a SHA-3 final operation is performed to calculate a message digest followed by an immediate SHA-3 init to re-initialize the "entropy pool". The obtained message digest is one block of the Jitter RNG that is returned to the caller. Mathematically speaking, the random number generated by the Jitter RNG is: aux_t = SHA-3(Jitter RNG state data) Jitter RNG block = SHA-3(time_i || aux_i || time_(i-1) || aux_(i-1) || ... || time_(i-255) || aux_(i-255)) when assuming that the OSR = 1, i.e. the default value. This operation implies that the Jitter RNG has an output-blocksize of 256 bits instead of the 64 bits of the LFSR-based Jitter RNG that is replaced with this patch. The patch also replaces the varying number of invocations of the conditioning function with one fixed number of invocations. The use of the conditioning function consistent with the userspace Jitter RNG library version 3.4.0. The code is tested with a system that exhibited the least amount of entropy generated by the Jitter RNG: the SiFive Unmatched RISC-V system. The measured entropy rate is well above the heuristically implied entropy value of 1 bit of entropy per time delta. On all other tested systems, the measured entropy rate is even higher by orders of magnitude. The measurement was performed using updated tooling provided with the user space Jitter RNG library test framework. The performance of the Jitter RNG with this patch is about en par with the performance of the Jitter RNG without the patch. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitter - permanent and intermittent health errorsStephan Müller2023-04-061-27/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to SP800-90B, two health failures are allowed: the intermittend and the permanent failure. So far, only the intermittent failure was implemented. The permanent failure was achieved by resetting the entire entropy source including its health test state and waiting for two or more back-to-back health errors. This approach is appropriate for RCT, but not for APT as APT has a non-linear cutoff value. Thus, this patch implements 2 cutoff values for both RCT/APT. This implies that the health state is left untouched when an intermittent failure occurs. The noise source is reset and a new APT powerup-self test is performed. Yet, whith the unchanged health test state, the counting of failures continues until a permanent failure is reached. Any non-failing raw entropy value causes the health tests to reset. The intermittent error has an unchanged significance level of 2^-30. The permanent error has a significance level of 2^-60. Considering that this level also indicates a false-positive rate (see SP800-90B section 4.2) a false-positive must only be incurred with a low probability when considering a fleet of Linux kernels as a whole. Hitting the permanent error may cause a panic(), the following calculation applies: Assuming that a fleet of 10^9 Linux kernels run concurrently with this patch in FIPS mode and on each kernel 2 health tests are performed every minute for one year, the chances of a false positive is about 1:1000 based on the binomial distribution. In addition, any power-up health test errors triggered with jent_entropy_init are treated as permanent errors. A permanent failure causes the entire entropy source to permanently return an error. This implies that a caller can only remedy the situation by re-allocating a new instance of the Jitter RNG. In a subsequent patch, a transparent re-allocation will be provided which also changes the implied heuristic entropy assessment. In addition, when the kernel is booted with fips=1, the Jitter RNG is defined to be part of a FIPS module. The permanent error of the Jitter RNG is translated as a FIPS module error. In this case, the entire FIPS module must cease operation. This is implemented in the kernel by invoking panic(). The patch also fixes an off-by-one in the RCT cutoff value which is now set to 30 instead of 31. This is because the counting of the values starts with 0. Reviewed-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Stephan Mueller <smueller@chronox.de> Reviewed-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitter - don't limit ->health_failure check to FIPS modeNicolai Stange2021-12-111-6/+0
| | | | | | | | | | | | | | | | | | | | | | | The jitterentropy's Repetition Count Test (RCT) as well as the Adaptive Proportion Test (APT) are run unconditionally on any collected samples. However, their result, i.e. ->health_failure, will only get checked if fips_enabled is set, c.f. the jent_health_failure() wrapper. I would argue that a RCT or APT failure indicates that something's seriously off and that this should always be reported as an error, independently of whether FIPS mode is enabled or not: it should be up to callers whether or not and how to handle jitterentropy failures. Make jent_health_failure() to unconditionally return ->health_failure, independent of whether fips_enabled is set. Note that fips_enabled isn't accessed from the jitterentropy code anymore now. Remove the linux/fips.h include as well as the jent_fips_enabled() wrapper. Signed-off-by: Nicolai Stange <nstange@suse.de> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: algapi - Remove skbuff.h inclusionHerbert Xu2020-08-201-1/+1
| | | | | | | | | | | | The header file algapi.h includes skbuff.h unnecessarily since all we need is a forward declaration for struct sk_buff. This patch removes that inclusion. Unfortunately skbuff.h pulls in a lot of things and drivers over the years have come to rely on it so this patch adds a lot of missing inclusions that result from this. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* mm, treewide: rename kzfree() to kfree_sensitive()Waiman Long2020-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or something. The "zero" part of the interface isn't even _relevant_. The main reason that kzfree() exists is to clear sensitive information that should not be leaked to other future users of the same memory objects. Rename kzfree() to kfree_sensitive() to follow the example of the recently added kvfree_sensitive() and make the intention of the API more explicit. In addition, memzero_explicit() is used to clear the memory to make sure that it won't get optimized away by the compiler. The renaming is done by using the command sequence: git grep -w --name-only kzfree |\ xargs sed -i 's/kzfree/kfree_sensitive/' followed by some editing of the kfree_sensitive() kerneldoc and adding a kzfree backward compatibility macro in slab.h. [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h] [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more] Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: David Howells <dhowells@redhat.com> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Joe Perches <joe@perches.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: David Rientjes <rientjes@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: "Jason A . Donenfeld" <Jason@zx2c4.com> Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* crypto: jitter - SP800-90B complianceStephan Müller2020-04-241-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SP800-90B specifies various requirements for the noise source(s) that may seed any DRNG including SP800-90A DRBGs. In November 2020, SP800-90B will be mandated for all noise sources that provide entropy to DRBGs as part of a FIPS 140-[2|3] validation or other evaluation types. Without SP800-90B compliance, a noise source is defined to always deliver zero bits of entropy. This patch ports the SP800-90B compliance from the user space Jitter RNG version 2.2.0. The following changes are applied: - addition of (an enhanced version of) the repetitive count test (RCT) from SP800-90B section 4.4.1 - the enhancement is due to the fact of using the stuck test as input to the RCT. - addition of the adaptive proportion test (APT) from SP800-90B section 4.4.2 - update of the power-on self test to perform a test measurement of 1024 noise samples compliant to SP800-90B section 4.3 - remove of the continuous random number generator test which is replaced by APT and RCT Health test failures due to the SP800-90B operation are only enforced in FIPS mode. If a runtime health test failure is detected, the Jitter RNG is reset. If more than 1024 resets in a row are performed, a permanent error is returned to the caller. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitter - add header to fix buildwarningsBen Dooks2019-10-181-7/+1
| | | | | | | | | | | | | | | | | | | | | Fix the following build warnings by adding a header for the definitions shared between jitterentropy.c and jitterentropy-kcapi.c. Fixes the following: crypto/jitterentropy.c:445:5: warning: symbol 'jent_read_entropy' was not declared. Should it be static? crypto/jitterentropy.c:475:18: warning: symbol 'jent_entropy_collector_alloc' was not declared. Should it be static? crypto/jitterentropy.c:509:6: warning: symbol 'jent_entropy_collector_free' was not declared. Should it be static? crypto/jitterentropy.c:516:5: warning: symbol 'jent_entropy_init' was not declared. Should it be static? crypto/jitterentropy-kcapi.c:59:6: warning: symbol 'jent_zalloc' was not declared. Should it be static? crypto/jitterentropy-kcapi.c:64:6: warning: symbol 'jent_zfree' was not declared. Should it be static? crypto/jitterentropy-kcapi.c:69:5: warning: symbol 'jent_fips_enabled' was not declared. Should it be static? crypto/jitterentropy-kcapi.c:74:6: warning: symbol 'jent_panic' was not declared. Should it be static? crypto/jitterentropy-kcapi.c:79:6: warning: symbol 'jent_memcpy' was not declared. Should it be static? crypto/jitterentropy-kcapi.c:93:6: warning: symbol 'jent_get_nstime' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Stephan Mueller <smueller@chronox.de Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Herbert Xu2019-06-201-1/+1
|\ | | | | | | Merge crypto tree to pick up vmx changes.
| * crypto: jitterentropy - change back to module_init()Eric Biggers2019-05-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "jitterentropy_rng" doesn't have any other implementations, nor is it tested by the crypto self-tests. So it was unnecessary to change it to subsys_initcall. Also it depends on the main clocksource being initialized, which may happen after subsys_initcall, causing this error: jitterentropy: Initialization failed with host not compliant with requirements: 2 Change it back to module_init(). Fixes: c4741b230597 ("crypto: run initcalls for generic implementations earlier") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* | crypto: jitter - update implementation to 2.1.2Stephan Müller2019-06-061-5/+0
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Jitter RNG implementation is updated to comply with upstream version 2.1.2. The change covers the following aspects: * Time variation measurement is conducted over the LFSR operation instead of the XOR folding * Invcation of stuck test during initialization * Removal of the stirring functionality and the Von-Neumann unbiaser as the LFSR using a primitive and irreducible polynomial generates an identical distribution of random bits This implementation was successfully used in FIPS 140-2 validations as well as in German BSI evaluations. This kernel implementation was tested as follows: * The unchanged kernel code file jitterentropy.c is compiled as part of user space application to generate raw unconditioned noise data. That data is processed with the NIST SP800-90B non-IID test tool to verify that the kernel code exhibits an equal amount of noise as the upstream Jitter RNG version 2.1.2. * Using AF_ALG with the libkcapi tool of kcapi-rng the Jitter RNG was output tested with dieharder to verify that the output does not exhibit statistical weaknesses. The following command was used: kcapi-rng -n "jitterentropy_rng" -b 100000000000 | dieharder -a -g 200 * The unchanged kernel code file jitterentropy.c is compiled as part of user space application to test the LFSR implementation. The LFSR is injected a monotonically increasing counter as input and the output is fed into dieharder to verify that the LFSR operation does not exhibit statistical weaknesses. * The patch was tested on the Muen separation kernel which returns a more coarse time stamp to verify that the Jitter RNG does not cause regressions with its initialization test considering that the Jitter RNG depends on a high-resolution timer. Tested-by: Reto Buerki <reet@codelabs.ch> Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: run initcalls for generic implementations earlierEric Biggers2019-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | Use subsys_initcall for registration of all templates and generic algorithm implementations, rather than module_init. Then change cryptomgr to use arch_initcall, to place it before the subsys_initcalls. This is needed so that when both a generic and optimized implementation of an algorithm are built into the kernel (not loadable modules), the generic implementation is registered before the optimized one. Otherwise, the self-tests for the optimized implementation are unable to allocate the generic implementation for the new comparison fuzz tests. Note that on arm, a side effect of this change is that self-tests for generic implementations may run before the unaligned access handler has been installed. So, unaligned accesses will crash the kernel. This is arguably a good thing as it makes it easier to detect that type of bug. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitterentropy - drop duplicate header module.hGeliang Tang2016-11-171-1/+0
| | | | | | | Drop duplicate header module.h from jitterentropy-kcapi.c. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitterentropy - use ktime_get_ns as fallbackStephan Mueller2016-06-241-9/+13
| | | | | | | | | | | | | | | | | | | | | | | As part of the Y2038 development, __getnstimeofday is not supposed to be used any more. It is now replaced with ktime_get_ns. The Jitter RNG uses the time stamp to measure the execution time of a given code path and tries to detect variations in the execution time. Therefore, the only requirement the Jitter RNG has, is a sufficient high resolution to detect these variations. The change was tested on x86 to show an identical behavior as RDTSC. The used test code simply measures the execution time of the heart of the RNG: jent_get_nstime(&time); jent_memaccess(ec, min); jent_fold_time(NULL, time, &folded, min); jent_get_nstime(&time2); return ((time2 - time)); Signed-off-by: Stephan Mueller <smueller@chronox.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitterentropy - remove unnecessary information from a commentAlexander Kuleshov2015-10-141-4/+0
| | | | | | | | | | The clocksource does not provide clocksource_register() function since f893598 commit (clocksource: Mostly kill clocksource_register()), so let's remove unnecessary information about this function from a comment. Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitterentropy - use safe format string parametersKees Cook2015-07-281-1/+1
| | | | | | | | | | Since the API for jent_panic() does not include format string parameters, adjust the call to panic() to use a literal string to avoid any future callers from leaking format strings into the panic message. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: jitterentropy - avoid compiler warningsStephan Mueller2015-06-251-0/+208
The core of the Jitter RNG is intended to be compiled with -O0. To ensure that the Jitter RNG can be compiled on all architectures, separate out the RNG core into a stand-alone C file that can be compiled with -O0 which does not depend on any kernel include file. As no kernel includes can be used in the C file implementing the core RNG, any dependencies on kernel code must be extracted. A second file provides the link to the kernel and the kernel crypto API that can be compiled with the regular compile options of the kernel. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>