- 16 Jul, 2020 27 commits
-
-
Eric Biggers authored
Now that there's a function that calculates the SHA-256 digest of a buffer in one step, use it instead of sha256_init() + sha256_update() + sha256_final(). Also simplify the code by inlining calculate_sha256() into its caller and switching a debug log statement to use %*phN instead of bin2hex(). Acked-by:
Tzung-Bi Shih <tzungbi@google.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Cc: alsa-devel@alsa-project.org Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Cheng-Yi Chiang <cychiang@chromium.org> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Guenter Roeck <groeck@chromium.org> Cc: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Eric Biggers authored
Now that there's a function that calculates the SHA-256 digest of a buffer in one step, use it instead of sha256_init() + sha256_update() + sha256_final(). Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Cc: mptcp@lists.01.org Cc: Mat Martineau <mathew.j.martineau@linux.intel.com> Cc: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Eric Biggers authored
Now that there's a function that calculates the SHA-256 digest of a buffer in one step, use it instead of sha256_init() + sha256_update() + sha256_final(). Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Cc: linux-efi@vger.kernel.org Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Eric Biggers authored
Add a function sha256() which computes a SHA-256 digest in one step, combining sha256_init() + sha256_update() + sha256_final(). This is similar to how we also have blake2s(). Reviewed-by:
-
Eric Biggers authored
To avoid a naming collision when we add a sha256() library function, rename the "sha256" static variable in sha256_glue.c to "sha256_alg". For consistency, also rename "sha224" to "sha224_alg". Reported-by:
kernel test robot <lkp@intel.com> Cc: sparclinux@vger.kernel.org Signed-off-by:
-
Ard Biesheuvel authored
Due to the fact that the x86 port does not support allocating objects on the stack with an alignment that exceeds 8 bytes, we have a rather ugly hack in the x86 code for ChaCha to ensure that the state array is aligned to 16 bytes, allowing the SSE3 implementation of the algorithm to use aligned loads. Given that the performance benefit of using of aligned loads appears to be limited (~0.25% for 1k blocks using tcrypt on a Corei7-8650U), and the fact that this hack has leaked into generic ChaCha code, let's just remove it. Cc: Martin Willi <martin@strongswan.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Martin Willi <martin@strongswan.org> Reviewed-by:
-
Herbert Xu authored
This patch adds a declaration for chacha20poly1305_selftest to silence a sparse warning. Signed-off-by: -
Ard Biesheuvel authored
The Mediatek accelerator driver calls into a dynamically allocated skcipher of the ctr(aes) variety to perform GCM key derivation, which involves AES encryption of a single block consisting of NUL bytes. There is no point in using the skcipher API for this, so use the AES library interface instead. Signed-off-by:
-
Ard Biesheuvel authored
Even though the sahara driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Ard Biesheuvel authored
Even though the qce driver implements asynchronous versions of ecb(aes), cbc(aes)and xts(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. While at it, remove the pointless memset() from qce_skcipher_init(), and remove the call to it qce_skcipher_init_fallback(). Signed-off-by:
-
Ard Biesheuvel authored
Even though the picoxcell driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
Jamie Iles <jamie@jamieiles.com> Signed-off-by:
-
Ard Biesheuvel authored
Even though the mxs-dcp driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
-
Ard Biesheuvel authored
Even though the chelsio driver implements asynchronous versions of cbc(aes) and xts(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
-
Ard Biesheuvel authored
Even though the ccp driver implements an asynchronous version of xts(aes), the fallback it allocates is required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
John Allen <john.allen@amd.com> Signed-off-by:
-
Ard Biesheuvel authored
Even though the sun8i-ss driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by:
-
Ard Biesheuvel authored
Even though the sun8i-ce driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
-
Ard Biesheuvel authored
Even though the sun4i driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
-
Ard Biesheuvel authored
Even though the omap-aes driver implements asynchronous versions of ecb(aes), cbc(aes) and ctr(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
-
Ard Biesheuvel authored
Even though the amlogic-gxl driver implements asynchronous versions of ecb(aes) and cbc(aes), the fallbacks it allocates are required to be synchronous. Given that SIMD based software implementations are usually asynchronous as well, even though they rarely complete asynchronously (this typically only happens in cases where the request was made from softirq context, while SIMD was already in use in the task context that it interrupted), these implementations are disregarded, and either the generic C version or another table based version implemented in assembler is selected instead. Since falling back to synchronous AES is not only a performance issue, but potentially a security issue as well (due to the fact that table based AES is not time invariant), let's fix this, by allocating an ordinary skcipher as the fallback, and invoke it with the completion routine that was given to the outer request. Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Signed-off-by:
-
Ard Biesheuvel authored
The AmLogic GXL crypto accelerator driver is built into the kernel if ARCH_MESON is set. However, given the single image policy of arm64, its defconfig enables all platforms by default, and so ARCH_MESON is usually enabled. This means that the AmLogic driver causes the arm64 defconfig build to pull in a huge chunk of the crypto stack as a builtin as well, which is undesirable, so let's make the amlogic GXL driver default to 'm' instead. Signed-off-by:
-
Herbert Xu authored
There are multiple things in this file that requires kernel.h but it's only included through other header files indirectly. This patch adds a direct inclusion as those indirect inclusions may go away at any point. Signed-off-by: -
Longfang Liu authored
Modify some log output interfaces and update author information Signed-off-by:
Longfang Liu <liulongfang@huawei.com> Signed-off-by:
-
Longfang Liu authored
Update debugfs interface parameters, and adjust the processing logic inside the corresponding function Signed-off-by:
-
Longfang Liu authored
Updates the initialization and reset of SEC driver's register operation. Signed-off-by:
-
Kai Ye authored
As before, if a SEC queue is at the 'fake busy' status, the request with a 'fake busy' flag will be sent into hardware and the sending function returns busy. After the request is finished, SEC driver's call back will identify the 'fake busy' flag, and notifies the user that hardware is not busy now by calling user's call back function. Now, a request sent into busy hardware will be cached in the SEC queue's backlog, return '-EBUSY' to user. After the request being finished, the cached requests will be processed in the call back function. to notify the corresponding user that SEC queue can process more requests. Signed-off-by:
Kai Ye <yekai13@huawei.com> Reviewed-by:
-
Kai Ye authored
SEC debug registers aren't cleared even if its driver is removed, so add a clearing operation in driver removing. Signed-off-by:
-
Herbert Xu authored
The arc4 algorithm requires storing state in the request context in order to allow more than one encrypt/decrypt operation. As this driver does not seem to do that, it means that using it for more than one operation is broken. Fixes: eaed71a4 ("crypto: caam - add ecb(*) support") Link: https://lore.kernel.org/linux-crypto/CAMj1kXGvMe_A_iQ43Pmygg9xaAM-RLy=_M=v+eg--8xNmv9P+w@mail.gmail.com Link: https://lore.kernel.org/linux-crypto/20200702101947.682-1-ardb@kernel.orgSigned-off-by:
-
- 09 Jul, 2020 13 commits
-
-
Ard Biesheuvel authored
Of the two versions of GHASH that the ARM driver implements, only one performs aggregation, and so the other one has no use for the powers of H to be precomputed, or space to be allocated for them in the key struct. So make the context size dependent on which version is being selected, and while at it, use a static key to carry this decision, and get rid of the function pointer. Signed-off-by:
-
Ard Biesheuvel authored
Introduce an inline wrapper for ghash_do_update() that incorporates the indirect call to the asm routine that is passed as an argument, and keep the non-SIMD fallback code out of line. This ensures that all references to the function pointer are inlined where the address is taken, removing the need for any indirect calls to begin with. Signed-off-by:
-
Ard Biesheuvel authored
Now that the ghash and gcm drivers are split, we no longer need to allocate a key struct for the former that carries powers of H that are only used by the latter. Also, take this opportunity to clean up the code a little bit. Signed-off-by:
-
Ard Biesheuvel authored
The remaining ghash implementation does not support aggregation, and so there is no point in including the precomputed powers of H in the key struct. So move that into the GCM setkey routine, and get rid of the shared sub-routine entirely. Signed-off-by:
-
Ard Biesheuvel authored
There are two ways to implement SIMD accelerated GCM on arm64: - using the PMULL instructions for carryless 64x64->128 multiplication, in which case the architecture guarantees that the AES instructions are available as well, and so we can use the AEAD implementation that combines both, - using the PMULL instructions for carryless 8x8->16 bit multiplication, which is implemented as a shash, and can be combined with any ctr(aes) implementation by the generic GCM AEAD template driver. So let's drop the 64x64->128 shash driver, which is never needed for GCM, and not suitable for use anywhere else. Signed-off-by:
-
Barry Song authored
If users don't specify NUMA node, the driver will use the ZIP module near the CPU allocating acomp. Otherwise, it uses the ZIP module according to the requirement of users. Cc: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
Barry Song <song.bao.hua@hisilicon.com> Signed-off-by:
-
Barry Song authored
For a Linux server with NUMA, there are possibly multiple (de)compressors which are either local or remote to some NUMA node. Some drivers will automatically use the (de)compressor near the CPU calling acomp_alloc(). However, it is not necessarily correct because users who send acomp_req could be from different NUMA node with the CPU which allocates acomp. Just like kernel has kmalloc() and kmalloc_node(), here crypto can have same support. Cc: Seth Jennings <sjenning@redhat.com> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Vitaly Wool <vitaly.wool@konsulko.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Sedat Dilek authored
When building with LLVM_IAS=1 means using Clang's Integrated Assembly (IAS) from LLVM/Clang >= v10.0.1-rc1+ instead of GNU/as from GNU/binutils I see the following breakage in Debian/testing AMD64: <instantiation>:15:74: error: too many positional arguments PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, ^ arch/x86/crypto/aesni-intel_asm.S:1598:2: note: while in macro instantiation GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp) ^ <instantiation>:47:2: error: unknown use of instruction mnemonic without a size suffix GHASH_4_ENCRYPT_4_PARALLEL_dec %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc ^ arch/x86/crypto/aesni-intel_asm.S:1599:2: note: while in macro instantiation GCM_ENC_DEC dec ^ <instantiation>:15:74: error: too many positional arguments PRECOMPUTE 8*3+8(%rsp), %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, ^ arch/x86/crypto/aesni-intel_asm.S:1686:2: note: while in macro instantiation GCM_INIT %r9, 8*3 +8(%rsp), 8*3 +16(%rsp), 8*3 +24(%rsp) ^ <instantiation>:47:2: error: unknown use of instruction mnemonic without a size suffix GHASH_4_ENCRYPT_4_PARALLEL_enc %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7, %xmm8, enc ^ arch/x86/crypto/aesni-intel_asm.S:1687:2: note: while in macro instantiation GCM_ENC_DEC enc Craig Topper suggested me in ClangBuiltLinux issue #1050: > I think the "too many positional arguments" is because the parser isn't able > to handle the trailing commas. > > The "unknown use of instruction mnemonic" is because the macro was named > GHASH_4_ENCRYPT_4_PARALLEL_DEC but its being instantiated with > GHASH_4_ENCRYPT_4_PARALLEL_dec I guess gas ignores case on the > macro instantiation, but llvm doesn't. First, I removed the trailing comma in the PRECOMPUTE line. Second, I substituted: 1. GHASH_4_ENCRYPT_4_PARALLEL_DEC -> GHASH_4_ENCRYPT_4_PARALLEL_dec 2. GHASH_4_ENCRYPT_4_PARALLEL_ENC -> GHASH_4_ENCRYPT_4_PARALLEL_enc With these changes I was able to build with LLVM_IAS=1 and boot on bare metal. I confirmed that this works with Linux-kernel v5.7.5 final. NOTE: This patch is on top of Linux v5.7 final. Thanks to Craig and especially Nick for double-checking and his comments. Suggested-by:Craig Topper <craig.topper@intel.com> Suggested-by:
Craig Topper <craig.topper@gmail.com> Suggested-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
-
Herbert Xu authored
This patch fixes a number of endianness marking issues in the ccp driver. Signed-off-by:
-
Herbert Xu authored
Some user-space programs rely on crypto requests that have no control metadata. This broke when a check was added to require the presence of control metadata with the ctx->init flag. This patch fixes the regression by setting ctx->init as long as one sendmsg(2) has been made, with or without a control message. Reported-by:
Sachin Sant <sachinp@linux.vnet.ibm.com> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Fixes: f3c802a1 ("crypto: algif_aead - Only wake up when...") Signed-off-by:
-
Rikard Falkeborn authored
features[] and id_table[] are not modified and can be made const to allow the compiler to put them in read-only memory. Before: text data bss dec hex filename 11534 2056 160 13750 35b6 drivers/crypto/virtio/virtio_crypto_core.o After: text data bss dec hex filename 11630 1992 128 13750 35b6 drivers/crypto/virtio/virtio_crypto_core.o Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Rikard Falkeborn authored
id_table[] is not modified and an be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 1746 192 8 1946 79a drivers/char/hw_random/virtio-rng.o After: text data bss dec hex filename 1762 176 8 1946 79a drivers/char/hw_random/virtio-rng.o Signed-off-by:
-
Rikard Falkeborn authored
nmk_rng_ids[] is not modified and can be made const to allow the compiler to put it in read-only memory. Before: text data bss dec hex filename 652 216 4 872 368 drivers/char/hw_random/nomadik-rng.o After: text data bss dec hex filename 676 192 4 872 368 drivers/char/hw_random/nomadik-rng.o Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
