- 11 Feb, 2022 5 commits
-
-
Ard Biesheuvel authored
The ARM version of the accelerated XOR routines are simply the 8-way C routines passed through the auto-vectorizer with SIMD codegen enabled. This used to require GCC version 4.6 at least, but given that 5.1 is now the baseline, this check is no longer necessary, and actually misidentifies Clang as GCC < 4.6 as Clang defines the GCC major/minor as well, but makes no attempt at doing this in a way that conveys feature parity with a certain version of GCC (which would not be a great idea in the first place). So let's drop the version check, and make the auto-vectorize pragma (which is based on a GCC-specific command line option) GCC-only. Since Clang performs SIMD auto-vectorization by default at -O2, no pragma is necessary here. Tested-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://github.com/ClangBuiltLinux/linux/issues/496 Link: https://github.com/ClangBuiltLinux/linux/issues/503Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Ard Biesheuvel authored
Modern compilers are perfectly capable of extracting parallelism from the XOR routines, provided that the prototypes reflect the nature of the input accurately, in particular, the fact that the input vectors are expected not to overlap. This is not documented explicitly, but is implied by the interchangeability of the various C routines, some of which use temporary variables while others don't: this means that these routines only behave identically for non-overlapping inputs. So let's decorate these input vectors with the __restrict modifier, which informs the compiler that there is no overlap. While at it, make the input-only vectors pointer-to-const as well. Tested-by:
-
Tudor Ambarus authored
Add support for the TDES IP found on sama7g5. Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
-
Stephan Müller authored
FIPS 140 requires a minimum security strength of 112 bits. This implies that the HMAC key must not be smaller than 112 in FIPS mode. This restriction implies that the test vectors for HMAC that have a key that is smaller than 112 bits must be disabled when FIPS support is compiled. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Stephan Müller authored
By adding the support for the flag fips_skip, hash / HMAC test vectors may be marked to be not applicable in FIPS mode. Such vectors are silently skipped in FIPS mode. Signed-off-by:
-
- 05 Feb, 2022 18 commits
-
-
Colin Ian King authored
Pointers in_sg and out_sg are being initialized with values that are never read, they are being re-assigned the same values later on. The initializations are redundant, remove them in preference to the later assignments that are closer to when the pointers are being used. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Colin Ian King authored
Variable c_size is being initialized with a value that is never read, it is being re-assigned with a different value later on. The initialization is redundant and can be removed. Signed-off-by:
-
Shijith Thotton authored
No issues were found while using the driver with dm-crypt enabled. So CONFIG_DM_CRYPT check in the driver can be removed. This also fixes the NULL pointer dereference in driver release if CONFIG_DM_CRYPT is enabled. ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... Call trace: crypto_unregister_alg+0x68/0xfc crypto_unregister_skciphers+0x44/0x60 otx2_cpt_crypto_exit+0x100/0x1a0 otx2_cptvf_remove+0xf8/0x200 pci_device_remove+0x3c/0xd4 __device_release_driver+0x188/0x234 device_release_driver+0x2c/0x4c ... Fixes: 6f03f0e8 ("crypto: octeontx2 - register with linux crypto framework") Signed-off-by:
Shijith Thotton <sthotton@marvell.com> Signed-off-by:
-
Tianjia Zhang authored
The multibuffer algorithms was removed already in 2018, so it is necessary to clear the test code left by tcrypt. Suggested-by:
Tianjia Zhang <tianjia.zhang@linux.alibaba.com> Acked-by:
-
Kavyasree Kotagiri authored
This patch adds support for hardware version of AES and SHA IPs available on lan966x SoC. Signed-off-by:
Kavyasree Kotagiri <kavyasree.kotagiri@microchip.com> Reviewed-by:
-
Dominik Brodowski authored
In case the entropy quality is low, there may be less than one bit to credit in the call to add_hwgenerator_randomness(): The number of bytes returned by rng_get_data() multiplied by the current quality (in entropy bits per 1024 bits of input) must be larger than 128 to credit at least one bit. However, imx-rngc.c sets the quality to 19, but may return less than 32 bytes; hid_u2fzero.c sets the quality to 1; and users may override the quality setting manually. In case there is less than one bit to credit, keep track of it and add that credit to the next iteration. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Ard Biesheuvel authored
Even though the kernel's implementations of AES-XTS were updated to implement ciphertext stealing and can operate on inputs of any size larger than or equal to the AES block size, this feature is rarely used in practice. In fact, in the kernel, AES-XTS is only used to operate on 4096 or 512 byte blocks, which means that not only the ciphertext stealing is effectively dead code, the logic in the bit sliced NEON implementation to deal with fewer than 8 blocks at a time is also never used. Since the bit-sliced NEON driver already depends on the plain NEON version, which is slower but can operate on smaller data quantities more straightforwardly, let's fallback to the plain NEON implementation of XTS for any residual inputs that are not multiples of 128 bytes. This allows us to remove a lot of complicated logic that rarely gets exercised in practice. Signed-off-by:
-
Ard Biesheuvel authored
Instead of processing the entire input with the 8-way bit sliced algorithm, which is sub-optimal for inputs that are not a multiple of 128 bytes in size, invoke the plain NEON version of CTR for the remainder of the input after processing the bulk using 128 byte strides. This allows us to greatly simplify the asm code that implements CTR, and get rid of all the branches and special code paths. It also gains us a couple of percent of performance. Signed-off-by:
-
Ard Biesheuvel authored
Instead of falling back to C code to deal with the final bit of input that is not a round multiple of the block size, handle this in the asm code, permitting us to use overlapping loads and stores for performance, and implement the 16-byte wide XOR using a single NEON instruction. Since NEON loads and stores have a natural width of 16 bytes, we need to handle inputs of less than 16 bytes in a special way, but this rarely occurs in practice so it does not impact performance. All other input sizes can be consumed directly by the NEON asm code, although it should be noted that the core AES transform can still only process 128 bytes (8 AES blocks) at a time. Signed-off-by:
-
Ard Biesheuvel authored
Instead of falling back to C code to do a memcpy of the output of the last block, handle this in the asm code directly if possible, which is the case if the entire input is longer than 16 bytes. Cc: Nathan Huckleberry <nhuck@google.com> Cc: Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Srujana Challa authored
LDWB is getting incorrectly used in HW when CPT_AF_LF()_PTR_CTL[IQB_LDWB]=1 and CPT instruction queue has less than 320 free entries. So, increase HW instruction queue size by 320 and give 320 entries less for SW/NIX RX as a SW workaround. Signed-off-by:
Srujana Challa <schalla@marvell.com> Signed-off-by:
-
Srujana Challa authored
When CPT_AF_DIAG[FLT_DIS] = 0 and a CPT engine access to LLC/DRAM encounters a fault/poison, a rare case may result in unpredictable data being delivered to a CPT engine. So, this patch adds code to set FLT_DIS as a workaround. Signed-off-by:
-
Srujana Challa authored
When software sets CPT_AF_CTL[RNM_REQ_EN]=1 and RNM in not producing entropy(i.e., RNM_ENTROPY_STATUS[NORMAL_CNT] < 0x40), the first cycle of the response may be lost due to a conditional clocking issue. Due to this, the subsequent random number stream will be corrupted. So, this patch adds support to ensure RNM_ENTROPY_STATUS[NORMAL_CNT] = 0x40 before writing CPT_AF_CTL[RNM_REQ_EN] = 1, as a workaround. Signed-off-by:
-
Dominik Brodowski authored
For two reasons, current_quality may become zero within the rngd kernel thread: (1) The user lowers current_quality to 0 by writing to the sysfs module parameter file (note that increasing the quality from zero is without effect at the moment), or (2) there are two or more hwrng devices registered, and those which provide quality>0 are unregistered, but one with quality==0 remains. If current_quality is 0, the randomness is not trusted and cannot help to increase the entropy count. That will lead to continuous calls to the hwrngd thread and continuous stirring of the input pool with untrusted bits. Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Dominik Brodowski authored
In case the user-specified rng device is not working, it is not used; therefore cur_rng_set_by_user must not be set to 1. Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Dominik Brodowski authored
Using rng_buffer in add_early_randomness() may race with rng_dev_read(). Use rng_fillbuf instead, as it is otherwise only used within the kernel by hwrng_fillfn() and therefore never exposed to userspace. Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Dominik Brodowski authored
According to <linux/hw_random.h>, the @max parameter of the ->read callback "is a multiple of 4 and >= 32 bytes". That promise was not kept by add_early_randomness(), which only asked for 16 bytes. As rng_buffer_size() is at least 32, we can simply ask for 32 bytes. Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Dominik Brodowski authored
hw-random device drivers depend on the hw-random core being initialized. Make this ordering explicit, also for the case these drivers are built-in. As the core itself depends on misc_register() which is set up at subsys_initcall time, advance the initialization of the core (only) to the fs_initcall() level. Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
- 31 Jan, 2022 17 commits
-
-
Yury Norov authored
padata_do_parallel() calls cpumask_weight() to check if any bit of a given cpumask is set. We can do it more efficiently with cpumask_empty() because cpumask_empty() stops traversing the cpumask as soon as it finds first set bit, while cpumask_weight() counts all bits unconditionally. Signed-off-by:
Yury Norov <yury.norov@gmail.com> Signed-off-by:
-
Tomas Paukrt authored
This patch fixes a bug in scatterlist processing that may cause incorrect AES block encryption/decryption. Fixes: 2e6d793e ("crypto: mxs-dcp - Use sg_mapping_iter to copy data") Signed-off-by:
Tomas Paukrt <tomaspaukrt@email.cz> Signed-off-by:
-
Kai Ye authored
The kernel test rebot report this warning: Uninitialized variable: ret. The code flow may return value of ret directly. This value is an uninitialized variable, here is fix it. Signed-off-by:
Kai Ye <yekai13@huawei.com> Signed-off-by:
-
Kai Ye authored
Use the correct print format. Printing an unsigned int value should use %u instead of %d. Signed-off-by:
-
Kai Ye authored
The CTR counter is 32bit rollover default on the BD. But the NIST standard is 128bit rollover. it cause the testing failed, so need to fix the BD configuration. Signed-off-by:
-
Kai Ye authored
Fix the maximum length of AAD for the CCM mode due to the hardware limited. Signed-off-by:
-
Kai Ye authored
Modify the print of information that might lead to user misunderstanding. Currently only XTS mode need the fallback tfm when using 192bit key. Others algs not need soft fallback tfm. So others algs can return directly. Signed-off-by:
-
Kai Ye authored
Fixup icv(integrity check value) checking enabled wrong on Kunpeng 930 Signed-off-by:
-
Shijith Thotton authored
OcteonTX2 CPT driver will fail to link without devlink support. aarch64-linux-gnu-ld: otx2_cpt_devlink.o: in function `otx2_cpt_dl_egrp_delete': otx2_cpt_devlink.c:18: undefined reference to `devlink_priv' aarch64-linux-gnu-ld: otx2_cpt_devlink.o: in function `otx2_cpt_dl_egrp_create': otx2_cpt_devlink.c:9: undefined reference to `devlink_priv' aarch64-linux-gnu-ld: otx2_cpt_devlink.o: in function `otx2_cpt_dl_uc_info': otx2_cpt_devlink.c:27: undefined reference to `devlink_priv' Fixes: fed8f4d5 ("crypto: octeontx2 - parameters for custom engine groups") Signed-off-by:
-
Ard Biesheuvel authored
The C standard does not support dereferencing pointers that are not aligned with respect to the pointed-to type, and doing so is technically undefined behavior, even if the underlying hardware supports it. This means that conditionally dereferencing such pointers based on whether CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y is not the right thing to do, and actually results in alignment faults on ARM, which are fixed up on a slow path. Instead, we should use the unaligned accessors in such cases: on architectures that don't care about alignment, they will result in identical codegen whereas, e.g., codegen on ARM will avoid doubleword loads and stores but use ordinary ones, which are able to tolerate misalignment. Link: https://lore.kernel.org/linux-crypto/CAHk-=wiKkdYLY0bv+nXrcJz3NH9mAqPAafX7PpW5EwVtxsEu7Q@mail.gmail.com/Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Herbert Xu authored
The function crypto_authenc_decrypt_tail discards its flags argument and always relies on the flags from the original request when starting its sub-request. This is clearly wrong as it may cause the SLEEPABLE flag to be set when it shouldn't. Fixes: 92d95ba9 ("crypto: authenc - Convert to new AEAD interface") Reported-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Eric Biggers authored
The new convention for akcipher_alg::verify makes it unclear which values are the lengths of the signature and digest. Add local variables to make it clearer what is going on. Also rename the digest_size variable in pkcs1pad_sign(), as it is actually the digest *info* size, not the digest size which is different. Signed-off-by:
-
Eric Biggers authored
Before checking whether the expected digest_info is present, we need to check that there are enough bytes remaining. Fixes: a49de377 ("crypto: Add hash param to pkcs1pad") Cc: <stable@vger.kernel.org> # v4.6+ Cc: Tadeusz Struk <tadeusz.struk@linaro.org> Signed-off-by:
-
Eric Biggers authored
RSA PKCS#1 v1.5 signatures are required to be the same length as the RSA key size. RFC8017 specifically requires the verifier to check this (https://datatracker.ietf.org/doc/html/rfc8017#section-8.2.2). Commit a49de377 ("crypto: Add hash param to pkcs1pad") changed the kernel to allow longer signatures, but didn't explain this part of the change; it seems to be unrelated to the rest of the commit. Revert this change, since it doesn't appear to be correct. We can be pretty sure that no one is relying on overly-long signatures (which would have to be front-padded with zeroes) being supported, given that they would have been broken since commit c7381b01 ("crypto: akcipher - new verify API for public key algorithms"). Fixes: a49de377 ("crypto: Add hash param to pkcs1pad") Cc: <stable@vger.kernel.org> # v4.6+ Cc: Tadeusz Struk <tadeusz.struk@linaro.org> Suggested-by:
Vitaly Chikunov <vt@altlinux.org> Signed-off-by:
-
Eric Biggers authored
Commit c7381b01 ("crypto: akcipher - new verify API for public key algorithms") changed akcipher_alg::verify to take in both the signature and the actual hash and do the signature verification, rather than just return the hash expected by the signature as was the case before. To do this, it implemented a hack where the signature and hash are concatenated with each other in one scatterlist. Obviously, for this to work correctly, akcipher_alg::verify needs to correctly extract the two items from the scatterlist it is given. Unfortunately, it doesn't correctly extract the hash in the case where the signature is longer than the RSA key size, as it assumes that the signature's length is equal to the RSA key size. This causes a prefix of the hash, or even the entire hash, to be taken from the *signature*. (Note, the case of a signature longer than the RSA key size should not be allowed in the first place; a separate patch will fix that.) It is unclear whether the resulting scheme has any useful security properties. Fix this by correctly extracting the hash from the scatterlist. Fixes: c7381b01 ("crypto: akcipher - new verify API for public key algorithms") Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by:
-
Eric Biggers authored
The pkcs1pad template can be instantiated with an arbitrary akcipher algorithm, which doesn't make sense; it is specifically an RSA padding scheme. Make it check that the underlying algorithm really is RSA. Fixes: 3d5b1ecd ("crypto: rsa - RSA padding algorithm") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
-
Giovanni Cabiddu authored
The logic that detects, enables and disables pfvf interrupts was expecting a single CSR per VF. Instead, the source and mask register are two registers with a bit per VF. Due to this, the driver is reading and setting reserved CSRs and not masking the correct source of interrupts. Fix the access to the source and mask register for QAT GEN4 devices by removing the outer loop in adf_gen4_get_vf2pf_sources(), adf_gen4_enable_vf2pf_interrupts() and adf_gen4_disable_vf2pf_interrupts() and changing the helper macros ADF_4XXX_VM2PF_SOU and ADF_4XXX_VM2PF_MSK. Fixes: a9dc0d96 ("crypto: qat - add PFVF support to the GEN4 host driver") Signed-off-by:
Giovanni Cabiddu <giovanni.cabiddu@intel.com> Co-developed-by:
Siming Wan <siming.wan@intel.com> Signed-off-by:
Xin Zeng <xin.zeng@intel.com> Reviewed-by:
Wojciech Ziemba <wojciech.ziemba@intel.com> Reviewed-by:
Marco Chiappero <marco.chiappero@intel.com> Signed-off-by:
-
