- 10 Jun, 2017 2 commits
-
-
Tero Kristo authored
This is not used for anything, so drop it. Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
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 16 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:
-
Dan Carpenter authored
We recently added some new locking but missed the unlocks on these error paths in sha512_ctx_mgr_submit(). Fixes: c459bd7b ("crypto: sha512-mb - Protect sha512 mb ctx mgr access") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
-
Gilad Ben-Yossef authored
The tcrypt AEAD cycles speed tests disables irqs during the test, which is broken at the very least since commit '1425d2d1 ("crypto: tcrypt - Fix AEAD speed tests")' adds a wait for completion as part of the test and probably since switching to the new AEAD API. While the result of taking a cycle count diff may not mean much on SMP systems if the task migrates, it's good enough for tcrypt being the quick & dirty dev tool it is. It's also what all the other (i.e. hash) cycle speed tests do. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Reported-by:
Ofir Drang <ofir.drang@arm.com> Reviewed-by:
-
Herbert Xu authored
The API setkey checks for key sizes and alignment went AWOL during the skcipher conversion. This patch restores them. Cc: <stable@vger.kernel.org> Fixes: 4e6c3df4 ("crypto: skcipher - Add low-level skcipher...") Reported-by:
Baozeng <sploving1@gmail.com> Signed-off-by:
-
- 13 May, 2017 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull some more input subsystem updates from Dmitry Torokhov: "An updated xpad driver with a few more recognized device IDs, and a new psxpad-spi driver, allowing connecting Playstation 1 and 2 joypads via SPI bus" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: cros_ec_keyb - remove extraneous 'const' Input: add support for PlayStation 1/2 joypads connected via SPI Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth Input: xpad - sync supported devices with xboxdrv Input: xpad - sort supported devices by USB ID
-
