kernel/linux.git/crypto/jitterentropy.c, branch linux-7.1.y

crypto: jitterentropy - Use SHA-3 library

2026-03-09T20:27:21+00:00

Make the jitterentropy RNG use the SHA-3 library API instead of crypto_shash. This ends up being quite a bit simpler, as various dynamic allocations and error checks become unnecessary. Signed-off-by: David Howells Co-developed-by: Eric Biggers Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260226010005.43528-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: jitter - replace ARRAY_SIZE definition with header include

2025-07-18T10:52:01+00:00

The ARRAY_SIZE macro is already defined in linux/array_size.h This patch replaces the ARRAY_SIZE definition in jitterentropy.c with an include, to make the code cleaner, and help reduce the number of duplicate ARRAY_SIZE definitions in the codebase. Signed-off-by: Ruben Wauters Signed-off-by: Herbert Xu

crypto: jitter - Use min() to simplify jent_read_entropy()

2024-08-30T10:22:30+00:00

Use the min() macro to simplify the jent_read_entropy() function and improve its readability. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu

crypto: jitter - Replace http with https

2024-04-05T07:46:33+00:00

The PDF is also available via https. Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu

crypto: jitter - Remove duplicate word in comment

2024-04-05T07:46:33+00:00

s/in// Signed-off-by: Thorsten Blum Signed-off-by: Herbert Xu

crypto: jitter - use permanent health test storage

2023-10-27T10:04:25+00:00

The health test result in the current code is only given for the currently processed raw time stamp. This implies to react on the health test error, the result must be checked after each raw time stamp being processed. To avoid this constant checking requirement, any health test error is recorded and stored to be analyzed at a later time, if needed. This change ensures that the power-up test catches any health test error. Without that patch, the power-up health test result is not enforced. The introduced changes are already in use with the user space version of the Jitter RNG. Fixes: 04597c8dd6c4 ("jitter - add RCT/APT support for different OSRs") Reported-by: Joachim Vandersmissen Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: jitter - reuse allocated entropy collector

2023-10-13T10:31:07+00:00

In case a health test error occurs during runtime, the power-up health tests are rerun to verify that the noise source is still good and that the reported health test error was an outlier. For performing this power-up health test, the already existing entropy collector instance is used instead of allocating a new one. This change has the following implications: * The noise that is collected as part of the newly run health tests is inserted into the entropy collector and thus stirs the existing data present in there further. Thus, the entropy collected during the health test is not wasted. This is also allowed by SP800-90B. * The power-on health test is not affected by the state of the entropy collector, because it resets the APT / RCT state. The remainder of the state is unrelated to the health test as it is only applied to newly obtained time stamps. This change also fixes a bug report about an allocation while in an atomic lock (the lock is taken in jent_kcapi_random, jent_read_entropy is called and this can call jent_entropy_init). Fixes: 04597c8dd6c4 ("jitter - add RCT/APT support for different OSRs") Reported-by: Dan Carpenter Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: jitter - Allow configuration of memory size

2023-10-01T08:28:15+00:00

The memory size consumed by the Jitter RNG is one contributing factor in the amount of entropy that is gathered. As the amount of entropy directly correlates with the distance of the memory from the CPU, the caches that are possibly present on a given system have an impact on the collected entropy. Thus, the kernel compile time should offer a means to configure the amount of memory used by the Jitter RNG. Although this option could be turned into a runtime option (e.g. a kernel command line option), it should remain a compile time option as otherwise adminsitrators who may not have performed an entropy assessment may select a value that is inappropriate. The default value selected by the configuration is identical to the current Jitter RNG value. Thus, the patch should not lead to any change in the Jitter RNG behavior. To accommodate larger memory buffers, kvzalloc / kvfree is used. Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: jitter - add RCT/APT support for different OSRs

2023-10-01T08:28:15+00:00

The oversampling rate (OSR) value specifies the heuristically implied entropy in the recorded data - H_submitter = 1/osr. A different entropy estimate implies a different APT/RCT cutoff value. This change adds support for OSRs 1 through 15. This OSR can be selected by the caller of the Jitter RNG. For this patch, the caller still uses one hard-coded OSR. A subsequent patch allows this value to be configured. In addition, the power-up self test is adjusted as follows: * It allows the caller to provide an oversampling rate that should be tested with - commonly it should be the same as used for the actual runtime operation. This makes the power-up testing therefore consistent with the runtime operation. * It calls now jent_measure_jitter (i.e. collects the full entropy that can possibly be harvested by the Jitter RNG) instead of only jent_condition_data (which only returns the entropy harvested from the conditioning component). This should now alleviate reports where the Jitter RNG initialization thinks there is too little entropy. * The power-up test now solely relies on the (enhanced) APT and RCT test that is used as a health test at runtime. The code allowing the different OSRs as well as the power-up test changes are present in the user space version of the Jitter RNG 3.4.1 and thus was already in production use for some time. Reported-by "Ospan, Abylay" Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: jitter - Add clarifying comments to Jitter Entropy RCT cutoff values

2023-08-11T11:19:52+00:00

The RCT cutoff values are correct, but they don't exactly match the ones one would expect when computing them using the formula in SP800-90B. This discrepancy is due to the fact that the Jitter Entropy RCT starts at 1. To avoid any confusion by future reviewers, add some comments and explicitly subtract 1 from the "correct" cutoff values in the definitions. Signed-off-by: Joachim Vandersmissen Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu