pm24.git/crypto/jitterentropy.c, branch rust-6.12

crypto: jitter - Replace http with https

2024-04-05T07:46:33Z

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:33Z

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

crypto: jitter - use permanent health test storage

2023-10-27T10:04:25Z

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:07Z

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:15Z

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:15Z

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:52Z

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

crypto: jitter - correct health test during initialization

2023-06-02T10:21:32Z

With the update of the permanent and intermittent health errors, the actual indicator for the health test indicates a potential error only for the one offending time stamp gathered in the current iteration round. The next iteration round will "overwrite" the health test result. Thus, the entropy collection loop in jent_gen_entropy checks for the health test failure upon each loop iteration. However, the initialization operation checked for the APT health test once for an APT window which implies it would not catch most errors. Thus, the check for all health errors is now invoked unconditionally during each loop iteration for the startup test. With the change, the error JENT_ERCT becomes unused as all health errors are only reported with the JENT_HEALTH return code. This allows the removal of the error indicator. Fixes: 3fde2fe99aa6 ("crypto: jitter - permanent and intermittent health errors" ) Reported-by: Joachim Vandersmissen Signed-off-by: Stephan Mueller Signed-off-by: Herbert Xu

crypto: jitter - replace LFSR with SHA3-256

2023-05-12T10:48:01Z

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 Signed-off-by: Herbert Xu

crypto: jitter - permanent and intermittent health errors

2023-04-06T08:18:53Z

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 Signed-off-by: Stephan Mueller Reviewed-by: Marcelo Henrique Cerri Signed-off-by: Herbert Xu