- 12 Oct, 2023 3 commits
-
-
Herbert Xu authored
Remove zlib-deflate test vectors as it no longer exists in the kernel. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Reviewed-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 19 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 <giovanni.cabiddu@intel.com> Signed-off-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:
-
Gatien Chevallier authored
Try to conceal seed errors when possible. If, despite the error concealing tries, a seed error is still present, then return an error. A clock error does not compromise the hardware block and data can still be read from RNG_DR. Just warn that the RNG clock is too slow and clear RNG_SR. Signed-off-by:
-
Gatien Chevallier authored
The RNG driver should be capable of recovering from an error. Implement an error concealment API. This avoids irrecoverable RNG state. Signed-off-by:
-
Gatien Chevallier authored
The RNG present on STM32MP13x platforms introduces a customizable configuration and the conditional reset. STM32 RNG configuration should best fit the requirements of the platform. Therefore, put a platform-specific RNG configuration field in the platform data. Default RNG configuration for STM32MP13 is the NIST certified configuration [1]. While there, fix and the RNG init sequence to support all RNG versions. [1] https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/certificate/53Signed-off-by:
-
Gatien Chevallier authored
Use devm_platform_get_and_ioremap_resource() to get and ioremap a resource. Signed-off-by:
-
Gatien Chevallier authored
Introduce st,stm32mp13-rng compatible and add st,rng-lock-conf. If st,rng-lock-conf is set, the RNG configuration in RNG_CR, RNG_HTCR and RNG_NSCR will be locked. It is supported starting from the RNG version present in the STM32MP13 Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Herbert Xu authored
Select CRYPTO_AEAD so that crypto_has_aead is available. Fixes: 1383e2ab102c ("ipsec: Stop using crypto_has_alg") Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309202112.33V1Ezb1-lkp@intel.com/Signed-off-by:
-
Bartosz Golaszewski authored
Add the compatible string for QCom ICE on sa8775p SoCs. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
-
- 20 Sep, 2023 3 commits
-
-
Roxana Nicolescu authored
x86 optimized crypto modules are built as modules rather than build-in and they are not loaded when the crypto API is initialized, resulting in the generic builtin module (sha1-generic) being used instead. It was discovered when creating a sha1/sha256 checksum of a 2Gb file by using kcapi-tools because it would take significantly longer than creating a sha512 checksum of the same file. trace-cmd showed that for sha1/256 the generic module was used, whereas for sha512 the optimized module was used instead. Add module aliases() for these x86 optimized crypto modules based on CPU feature bits so udev gets a chance to load them later in the boot process. This resulted in ~3x decrease in the real-time execution of kcapi-dsg. Fix is inspired from commit aa031b8f ("crypto: x86/sha512 - load based on CPU features") where a similar fix was done for sha512. Cc: stable@vger.kernel.org # 5.15+ Suggested-by:
Julian Andres Klode <julian.klode@canonical.com> Signed-off-by:
Roxana Nicolescu <roxana.nicolescu@canonical.com> Signed-off-by:
-
Wenkai Lin authored
When sec_aead_mac_init returns an error code, sec_cipher_map will exit abnormally, the hardware sgl should be unmmaped. Signed-off-by:
Wenkai Lin <linwenkai6@hisilicon.com> Signed-off-by:
-
Adam Guerin authored
QAT GEN4 devices support chained compression operations. These allow, with a single request to firmware, to hash then compress data. Extend the configuration to enable such mode. The cfg_services operations in sysfs are extended to allow the string "dcc". When selected, the driver downloads to the device both the symmetric crypto and the compression firmware images and sends an admin message to firmware which enables `chained` operations. In addition, it sets the device's capabilities as the combination of compression and symmetric crypto capabilities, while excluding the ICP_ACCEL_CAPABILITIES_CRYPTO_SYMMETRIC bit to indicate that in this mode, symmetric crypto instances are not supported. When "dcc" is enabled, the device will handle compression requests as if the "dc" configuration is loaded ("dcc" is a variation of "dc") and the driver will register the acomp algorithms. As for the other extended configurations, "dcc" is only available for qat_4xxx devices and the chaining service will be only accessible from user space. Signed-off-by:Adam Guerin <adam.guerin@intel.com> Reviewed-by:
-
