- 13 Oct, 2023 10 commits
-
-
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by:Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
As skcipher spawns may be of the type lskcipher, only the common fields may be accessed. This was already the case but use the correct helpers to make this more obvious. Signed-off-by: -
Herbert Xu authored
Add code to handle an underlying lskcihper object when grabbing an skcipher spawn. Fixes: 31865c4c ("crypto: skcipher - Add lskcipher") Signed-off-by:
-
Herbert Xu authored
As skcipher spawns can be of two different types (skcipher vs. lskcipher), only the common fields can be accessed. Add a helper to return the common algorithm object. Signed-off-by: -
Herbert Xu authored
Replace skcipher implementation with lskcipher. Signed-off-by: -
Herbert Xu authored
As lskcipher requires the ecb wrapper for the transition add an explicit dependency on it so that it is always present. This can be removed once all simple ciphers have been converted to lskcipher. Reported-by:
Nathan Chancellor <nathan@kernel.org> Fixes: 705b52fe ("crypto: cbc - Convert from skcipher to lskcipher") Signed-off-by:
-
Giovanni Cabiddu authored
Create CRYPTO_QAT namespace for symbols exported by the qat_common module and import those in the QAT drivers. It will reduce the global namespace crowdedness and potential misuse or the API. This does not introduce any functional change. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by:
Lucas Segarra Fernandez <lucas.segarra.fernandez@intel.com> Reviewed-by:
-
- 12 Oct, 2023 3 commits
-
-
Herbert Xu authored
Remove zlib-deflate test vectors as it no longer exists in the kernel. Signed-off-by:
Ard Biesheuvel <ardb@kernel.org>
-
Herbert Xu authored
Remove the implementation of zlib-deflate because it is completely unused in the kernel. Signed-off-by:
-
Herbert Xu authored
Remove the implementation of zlib-deflate because it is completely unused in the kernel. Signed-off-by:
-
- 05 Oct, 2023 15 commits
-
-
Dimitri John Ledkov authored
Remove support for md4 md5 hash and signatures in x.509 certificate parsers, pkcs7 signature parser, authenticode parser. All of these are insecure or broken, and everyone has long time ago migrated to alternative hash implementations. Also remove md2 & md3 oids which have already didn't have support. This is also likely the last user of md4 in the kernel, and thus crypto/md4.c and related tests in tcrypt & testmgr can likely be removed. Other users such as cifs smbfs ext modpost sumversions have their own internal implementation as needed. Signed-off-by:
Dimitri John Ledkov <dimitri.ledkov@canonical.com> Reviewed-by:
Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by:
-
Randy Dunlap authored
Correct typo of "destination". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: linux-crypto@vger.kernel.org Signed-off-by:
-
Randy Dunlap authored
Correct typos of "destination". Signed-off-by:
-
Alexey Romanov authored
Add compatible for hardware number generator node for Amlogic S4-series. Signed-off-by:
Alexey Romanov <avromanov@sberdevices.ru> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Alexey Romanov authored
For some Amlogic SOC's, mechanism to obtain random number has been changed. For example, S4 now uses status bit waiting algo. Signed-off-by:
-
Weili Qian authored
When the Kunpeng accelerator executes tasks such as encryption and decryption have minimum requirements on the number of device queues. If the number of queues does not meet the requirement, the process initialization will fail. Therefore, the driver checks the number of queues on the device before registering the algorithm. If the number does not meet the requirements, the driver does not register the algorithm to crypto subsystem, the device is still added to the qm_list. Signed-off-by:
Weili Qian <qianweili@huawei.com> Signed-off-by:
-
Weili Qian authored
The type of aeq has only 4bits in dw0 17 to 20bits, but 15bits(17 to 31bits) are read in function qm_aeq_thread(). The remaining 11bits(21 to 31bits) are reserved for aeq, but may not be 0. To avoid getting incorrect value of type, other bits are cleared. Signed-off-by:
-
Longfang Liu authored
If the queue isolation feature is enabled, the number of queues supported by the device changes. When PF is enabled using the current default number of queues, the default number of queues may be greater than the number supported by the device. As a result, the PF fails to be bound to the driver. After modification, if queue isolation feature is enabled, when the default queue parameter is greater than the number supported by the device, the number of enabled queues will be changed to the number supported by the device, so that the PF and driver can be properly bound. Fixes: 8bbecfb4 ("crypto: hisilicon/qm - add queue isolation support for Kunpeng930") Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Signed-off-by:
-
Chang S. Bae authored
Currently, the alignment of each field in struct aesni_xts_ctx occurs right before every access. However, it's possible to perform this alignment ahead of time. Introduce a helper function that converts struct crypto_skcipher *tfm to struct aesni_xts_ctx *ctx and returns an aligned address. Utilize this helper function at the beginning of each XTS function and then eliminate redundant alignment code. Suggested-by:
Eric Biggers <ebiggers@kernel.org> Link: https://lore.kernel.org/all/ZFWQ4sZEVu%2FLHq+Q@gmail.com/Signed-off-by:
Chang S. Bae <chang.seok.bae@intel.com> Cc: linux-crypto@vger.kernel.org Cc: x86@kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Chang S. Bae authored
Currently, every field in struct aesni_xts_ctx is defined as a byte array of the same size as struct crypto_aes_ctx. This data type is obscure and the choice lacks justification. To rectify this, update the field type in struct aesni_xts_ctx to match its actual structure. Suggested-by:
-
Chang S. Bae authored
The address alignment code has been duplicated for each mode. Instead of duplicating the same code, refactor the alignment code and simplify the alignment helpers. Suggested-by:
-
Lukas Wunner authored
The ASN.1 module in RFC 5280 appendix A.1 uses EXPLICIT TAGS whereas the one in appendix A.2 uses IMPLICIT TAGS. The kernel's simplified asn1_compiler.c always uses EXPLICIT TAGS, hence definitions from appendix A.2 need to be annotated as IMPLICIT for the compiler to generate RFC-compliant code. In particular, GeneralName is defined in appendix A.2: GeneralName ::= CHOICE { otherName [0] OtherName, ... dNSName [2] IA5String, x400Address [3] ORAddress, directoryName [4] Name, ... } Because appendix A.2 uses IMPLICIT TAGS, the IA5String tag (0x16) of a dNSName is not rendered. Instead, the string directly succeeds the [2] tag (0x82). Likewise, the SEQUENCE tag (0x30) of an OtherName is not rendered. Instead, only the constituents of the SEQUENCE are rendered: An OID tag (0x06), a [0] tag (0xa0) and an ANY tag. That's three consecutive tags instead of a single encompassing tag. The situation is different for x400Address and directoryName choices: They reference ORAddress and Name, which are defined in appendix A.1, therefore use EXPLICIT TAGS. The AKID ASN.1 module is missing several IMPLICIT annotations, hence isn't RFC-compliant. In the unlikely event that an AKID contains other elements beside a directoryName, users may see parse errors. Add the missing annotations but do not tag this commit for stable as I am not aware of any issue reports. Fixes are only eligible for stable if they're "obviously correct" and with ASN.1 there's no such thing. Signed-off-by:Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Fabio Estevam authored
i.MX27 has only one Sahara interrupt. i.MX53 has two. Describe this difference. Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Fabio Estevam authored
Describe the clocks (ipg and ahb) needed by Sahara block to operate. Signed-off-by:
-
Fabio Estevam authored
In the title, there is no need to mention "included in some i.MX chips" as it is too vague. Remove it to make it simpler. While at it, also remove the extra space in the first reg entry. Signed-off-by:
-
- 01 Oct, 2023 12 commits
-
-
Uwe Kleine-König authored
All callers ignore the return value, so simplify by not providing one. Note that crypto_engine_exit() is typically called in a device driver's remove path (or the error path in probe), where errors cannot be handled anyhow. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
Returning an error code in the remove function of a platform device has no effect (compared to returning zero) apart from an error message, that the error is ignored. Then the device is removed irrespective of the returned value. As kmb_ocs_hcu_remove is only called after kmb_ocs_hcu_probe() returned successfully, platform_get_drvdata() never returns NULL and so the respective check can just be dropped. crypto_engine_exit() might return an error code but already emits an error message in that case, so better return zero in kmb_ocs_hcu_remove() even in this case to suppress another error message. All other crypto drivers also ignore the return value of crypto_engine_exit(). Signed-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct adf_fw_counters. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Tom Rix <trix@redhat.com> Cc: Adam Guerin <adam.guerin@intel.com> Cc: Lucas Segarra Fernandez <lucas.segarra.fernandez@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: qat-linux@intel.com Cc: linux-crypto@vger.kernel.org Cc: llvm@lists.linux.dev Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by:
-
Giovanni Cabiddu authored
Increase the size of the buffers used for composing the names used for the transport debugfs entries and the vector name to avoid a potential truncation. This resolves the following errors when compiling the driver with W=1 and KCFLAGS=-Werror on GCC 12.3.1: drivers/crypto/intel/qat/qat_common/adf_transport_debug.c: In function ‘adf_ring_debugfs_add’: drivers/crypto/intel/qat/qat_common/adf_transport_debug.c:100:60: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] drivers/crypto/intel/qat/qat_common/adf_isr.c: In function ‘adf_isr_resource_alloc’: drivers/crypto/intel/qat/qat_common/adf_isr.c:197:47: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 5 [-Werror=format-truncation=] Fixes: a672a9dc ("crypto: qat - Intel(R) QAT transport code") Signed-off-by:Damian Muszynski <damian.muszynski@intel.com> Signed-off-by:
-
Gaurav Jain authored
key buffer is not copied in chachapoly_setkey function, results in wrong output for encryption/decryption operation. fix this by memcpy the key in caam_ctx key arrary Fixes: d6bbd4ee ("crypto: caam/jr - add support for Chacha20 + Poly1305") Signed-off-by:
Gaurav Jain <gaurav.jain@nxp.com> Signed-off-by:
-
Stephan Müller authored
The oversampling rate used by the Jitter RNG allows the configuration of the heuristically implied entropy in one timing measurement. This entropy rate is (1 / OSR) bits of entropy per time stamp. Considering that the Jitter RNG now support APT/RCT health tests for different OSRs, allow this value to be configured at compile time to support systems with limited amount of entropy in their timer. The allowed range of OSR values complies with the APT/RCT cutoff health test values which range from 1 through 15. The default value of the OSR selection support is left at 1 which is the current default. Thus, the addition of the configuration support does not alter the default Jitter RNG behavior. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Stephan Müller authored
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 Müller authored
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" <aospan@amazon.com> Signed-off-by:
-
Gaurav Jain authored
key buffer is not copied in chachapoly_setkey function, results in wrong output for encryption/decryption operation. fix this by memcpy the key in caam_ctx key arrary Fixes: c10a5336 ("crypto: caam/qi2 - add support for Chacha20 + Poly1305") Signed-off-by:
-
Gatien Chevallier authored
Implement stm32_rng_suspend()/stm32_rng_resume() low-power APIs called when the hardware block context will be lost. There is no need to save the RNG_CR register in stm32_rng_runtime_suspend() as the context is not lost. Therefore, only enable/disable the RNG in the runtime sequences. Signed-off-by:
Gatien Chevallier <gatien.chevallier@foss.st.com> Signed-off-by:
-
Gatien Chevallier authored
If "st,rng-lock-conf" DT binding property is set for a stm32-rng node, the RNG configuration will be locked until next hardware block reset or platform reset. Signed-off-by:
-
Gatien Chevallier authored
For NIST certification the noise source sampling may need to be restrained. This change implements an algorithm that gets the rate of the RNG clock and apply the correct value in CLKDIV field in RNG_CR register to force the RNG clock rate to be "max_clock_rate" maximum. As it is platform-specific, implement it as a compat data. Signed-off-by:
-
