- 10 Jun, 2017 7 commits
-
-
Tero Kristo authored
Use the SG alignment APIs from the OMAP crypto support library instead of using own implementations. This reduces the amount of copy-paste code. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Tero Kristo authored
This contains the generic APIs for aligning SG buffers. Signed-off-by:
-
Tero Kristo authored
Convert the driver to use autosuspend for runtime_pm. This boosts the performance, and optimizes the power consumption for the driver. By default, the timeout value for autosuspend is set to one second. Signed-off-by:
-
Tero Kristo authored
OMAP DES crypto accelerator itself is unable to detect weak keys, so add a specific call to the generic des driver to check the key strength if requested. Signed-off-by:
-
Tero Kristo authored
AES can have multiple HW accelerator cores in the system, in which case each core has its own crypto engine in use. Currently, the used hardware device is stored under the omap_aes_ctx struct, which is global for the algorithm itself, causing conflicts when used with multiple cores. Fix this by moving the used HW device under reqctx, which is stored per-request basis. Signed-off-by:
-
Tero Kristo authored
This is not used for anything, so drop it. Signed-off-by:
-
Matthias Kaehlcke authored
This fixes the following warning when building with clang: crypto/rng.c:35:34: error: unused function '__crypto_rng_cast' [-Werror,-Wunused-function] Signed-off-by:Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
- 01 Jun, 2017 7 commits
-
-
Rick Altherr authored
When a hw_random device's quality is non-zero, it will automatically be used to fill the kernel's entropy pool. Since timeriomem_rng is used by many different devices, the quality needs to be provided by platform data or device tree. Signed-off-by:
Rick Altherr <raltherr@google.com> Signed-off-by:
-
Rick Altherr authored
Signed-off-by:
-
Ard Biesheuvel authored
Make the module autoloadable by tying it to the CPU feature bits that describe whether the optional instructions it relies on are implemented by the current CPU. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Ard Biesheuvel authored
Make the module autoloadable by tying it to the CPU feature bit that describes whether the optional instructions it relies on are implemented by the current CPU. Signed-off-by:
-
Ard Biesheuvel authored
Make the module autoloadable by tying it to the CPU feature bit that describes whether the optional instructions it relies on are implemented by the current CPU. Signed-off-by:
-
Ard Biesheuvel authored
Make the module autoloadable by tying it to the CPU feature bit that describes whether the optional instructions it relies on are implemented by the current CPU. Signed-off-by:
-
Ard Biesheuvel authored
Make the module autoloadable by tying it to the CPU feature bit that describes whether the optional instructions it relies on are implemented by the current CPU. Signed-off-by:
-
- 23 May, 2017 13 commits
-
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
Corentin Labbe <clabbe.montjoie@gmail.com> Acked-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
-
Corentin LABBE authored
This patch simply replace all occurrence of HMAC IPAD/OPAD value by their define. Signed-off-by:
-
Corentin LABBE authored
Many HMAC users directly use directly 0x36/0x5c values. It's better with crypto to use a name instead of directly some crypto constant. This patch simply add HMAC_IPAD_VALUE/HMAC_OPAD_VALUE defines in a new include file "crypto/hmac.h" and use them in crypto/hmac.c Signed-off-by:
-
Eric Biggers authored
When using the "aes-asm" implementation of AES (*not* the AES-NI implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the following warning was reported, along with a long unwinder dump: WARNING: kernel stack regs at ffffc90000643558 in kworker/u4:2:155 has bad 'bp' value 000000000000001c The problem is that aes_enc_block() and aes_dec_block() use %rbp as a temporary register, which breaks stack traces if an interrupt occurs. Fix this by replacing %rbp with %r9, which was being used to hold the saved value of %rbp. This required rearranging the AES round macro slightly since %r9d cannot be used as the target of a move from %ah-%dh. Performance is essentially unchanged --- actually about 0.2% faster than before. Interestingly, I also measured aes-generic as being nearly 7% faster than aes-asm, so perhaps aes-asm has outlived its usefulness... Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Arvind Yadav authored
Here, Clock enable can failed. So adding an error check for clk_prepare_enable. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Arvind Yadav authored
Here, Clock enable can failed. So adding an error check for clk_prepare_enable. Signed-off-by:
-
- 18 May, 2017 13 commits
-
-
Sabrina Dubroca authored
Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
-
Sabrina Dubroca authored
Signed-off-by:
-
Sabrina Dubroca authored
This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by:
-
Sabrina Dubroca authored
Signed-off-by:
-
Sabrina Dubroca authored
This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by:
-
Sabrina Dubroca authored
Signed-off-by:
-
Sabrina Dubroca authored
This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by:
-
Ard Biesheuvel authored
Replace the inline asm which exports struct offsets as ELF symbols with proper const variables exposing the same values. This works around an issue with Clang which does not interpret the "i" (or "I") constraints in the same way as GCC. Signed-off-by:
-
Gary R Hook authored
CC: <stable@vger.kernel.org> # 4.9.x+ Signed-off-by:
-
Radu Alexe authored
CAAM RSA private key may have either of three representations. 1. The first representation consists of the pair (n, d), where the components have the following meanings: n the RSA modulus d the RSA private exponent 2. The second representation consists of the triplet (p, q, d), where the components have the following meanings: p the first prime factor of the RSA modulus n q the second prime factor of the RSA modulus n d the RSA private exponent 3. The third representation consists of the quintuple (p, q, dP, dQ, qInv), where the components have the following meanings: p the first prime factor of the RSA modulus n q the second prime factor of the RSA modulus n dP the first factors's CRT exponent dQ the second factors's CRT exponent qInv the (first) CRT coefficient The benefit of using the third or the second key form is lower computational cost for the decryption and signature operations. This patch adds support for the third RSA private key representations and extends caampkc to use the fastest key when all related components are present in the private key. Signed-off-by:Tudor Ambarus <tudor-dan.ambarus@nxp.com> Signed-off-by:
Radu Alexe <radu.alexe@nxp.com> Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Radu Alexe authored
CAAM RSA private key may have either of three representations. 1. The first representation consists of the pair (n, d), where the components have the following meanings: n the RSA modulus d the RSA private exponent 2. The second representation consists of the triplet (p, q, d), where the components have the following meanings: p the first prime factor of the RSA modulus n q the second prime factor of the RSA modulus n d the RSA private exponent 3. The third representation consists of the quintuple (p, q, dP, dQ, qInv), where the components have the following meanings: p the first prime factor of the RSA modulus n q the second prime factor of the RSA modulus n dP the first factors's CRT exponent dQ the second factors's CRT exponent qInv the (first) CRT coefficient The benefit of using the third or the second key form is lower computational cost for the decryption and signature operations. This patch adds support for the second RSA private key representation. Signed-off-by: -
Radu Alexe authored
This function will be used into further patches. Signed-off-by:
-
Tudor Ambarus authored
The function returns NULL if buf is composed only of zeros. Signed-off-by:
-
