- 27 Jul, 2018 11 commits
-
-
Krzysztof Kozlowski authored
Do not define again the polynomial but use header with existing define. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Krzysztof Kozlowski authored
Do not define again the polynomial but use header with existing define. Signed-off-by:
-
Krzysztof Kozlowski authored
Do not define again the polynomial but use header with existing define. Signed-off-by:
-
Krzysztof Kozlowski authored
Header was defining CRCPOLY_LE/BE and CRC32C_POLY_LE but in fact all of them are CRC-32 polynomials so use consistent naming. Signed-off-by:
-
Krzysztof Kozlowski authored
Allow other drivers and parts of kernel to use the same define for CRC32 polynomial, instead of duplicating it in many places. This code does not bring any functional changes, except moving existing code. Signed-off-by:
-
Timur Tabi authored
Add support for probing on ACPI systems, with ACPI HID QCOM8160. On ACPI systems, clocks are always enabled, the PRNG should already be enabled, and the register region is read-only. The driver only verifies that the hardware is already enabled never tries to disable or configure it. Signed-off-by:
Timur Tabi <timur@codeaurora.org> Tested-by:
Jeffrey Hugo <jhugo@codeaurora.org> [port to crypto API] Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Vinod Koul authored
Qcom 8996 and later chips features multiple Execution Environments (EE) and secure world is typically responsible for configuring the prng. Add driver data for qcom,prng as 0 and qcom,prng-ee as 1 and use that to skip initialization routine. Signed-off-by:
-
Vinod Koul authored
Later qcom chips support v2 of the prng, which exposes an EE (Execution Environment) for OS to use so add new compatible qcom,prng-ee for this. Signed-off-by:
-
Vinod Koul authored
This ports the Qcom prng from older hw_random driver. No change of functionality and move from hw_random to crypto APIs is done. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Vinod Koul authored
Now that we are adding new driver for prng in crypto, move the binding as well. Signed-off-by:
-
Vinod Koul authored
This driver is for a psedo-rng so should not be added in hwrng. Remove it so that it's replacement can be added. Signed-off-by:
-
- 20 Jul, 2018 7 commits
-
-
Michael Müller authored
This patch fixes two typos related to unregistering algorithms supported by SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered in case of an error. In sahara_unregister_algs the wrong array is used to determine the iteration count. Signed-off-by:
Michael Müller <michael@fds-team.de> Signed-off-by:
-
Antoine Tenart authored
In the cipher safexcel_send_req function, GCC warns that first_rdesc may be used uninitialized. While this should never happen, this patch removes the warning by initializing this variable to NULL to make GCC happy. This was reported by the kbuild test robot. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Antoine Tenart authored
Use the appropriate SPDX license identifiers and drop the license text. This patch is only cosmetic. Signed-off-by:
-
Stephan Mueller authored
Fix the b value to be compliant with FIPS 186-4 D.1.2.1. This fix is required to make sure the SP800-56A public key test passes for P-192. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
-
Stephan Mueller authored
By adding a zero byte-length for the DH parameter Q value, the public key verification test is disabled for the given test. Reported-by:
Eric Biggers <ebiggers3@gmail.com> Signed-off-by:
-
Stephan Mueller authored
The CTR DRBG requires two SGLs pointing to input/output buffers for the CTR AES operation. The used SGLs always have only one entry. Thus, the SGL can be initialized during allocation time, preventing a re-initialization of the SGLs during each call. The performance is increased by about 1 to 3 percent depending on the size of the requested buffer size. Signed-off-by:
-
Gustavo A. R. Silva authored
In case memory resources for *base* were allocated, release them before return. Addresses-Coverity-ID: 1471702 ("Resource leak") Fixes: e3fe0ae1 ("crypto: dh - add public key verification test") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
-
- 13 Jul, 2018 6 commits
-
-
Gustavo A. R. Silva authored
Cast *val* to u64 in order to give the compiler complete information about the proper arithmetic to use. Notice that such variable is used in a context that expects an expression of type u64 (64 bits, unsigned) and the following expression is currently being evaluated using 32-bit arithmetic: val << bit_pos Addresses-Coverity-ID: 1467425 ("Unintentional integer overflow") Signed-off-by: -
Tom Lendacky authored
Add a new CCP/PSP PCI device ID and new PSP register offsets. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Acked-by:
Gary R Hook <gary.hook@amd.com> Reviewed-by:
Brijesh Singh <brijesh.singh@amd.com> Signed-off-by:
-
Tom Lendacky authored
In preparation for adding a new PSP device ID that uses different register offsets, add support to the PSP version data for register offset values. And then update the code to use these new register offset values. Signed-off-by:
-
Tom Lendacky authored
Remove some unused #defines for register offsets that are not used. This will lessen the changes required when register offsets change between versions of the device. Signed-off-by:
-
Tom Lendacky authored
Add a dev_notice() message to the PSP initialization to report when the PSP initialization has succeeded and the PSP is enabled. Signed-off-by:
-
Tom Lendacky authored
The wait_event() function is used to detect command completion. The interrupt handler will set the wait condition variable when the interrupt is triggered. However, the variable used for wait_event() is initialized after the command has been submitted, which can create a race condition with the interrupt handler and result in the wait_event() never returning. Move the initialization of the wait condition variable to just before command submission. Fixes: 200664d5 ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Cc: <stable@vger.kernel.org> # 4.16.x- Signed-off-by:
-
- 08 Jul, 2018 16 commits
-
-
Gilad Ben-Yossef authored
A debug print about register status post interrupt can happen quite often. Rate limit it to avoid cluttering the log. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Gilad Ben-Yossef authored
The ccree driver implemented NIST 800-38A CBC-CS2 ciphertext format, which only reverses the last two blocks if the stolen ciphertext amount are none zero. Move it to the kernel chosen format of CBC-CS3 which swaps the final blocks unconditionally and rename it to "cts" now that it complies with the kernel format and passes the self tests. Ironically, the CryptoCell REE HW does just that, so the fix is dropping the code that forced it to use plain CBC if the ciphertext was block aligned. Signed-off-by:
-
Gilad Ben-Yossef authored
Remove legacy code no longer used by anything. Signed-off-by:
-
Gilad Ben-Yossef authored
We were copying our last cipher block into the request for use as IV for all modes of operations. Fix this by discerning the behaviour based on the mode of operation used: copy ciphertext for CBC, update counter for CTR. CC: stable@vger.kernel.org Fixes: 63ee04c8 ("crypto: ccree - add skcipher support") Reported by: Hadar Gat <hadar.gat@arm.com> Signed-off-by:
-
Gilad Ben-Yossef authored
The testmgr hash tests were testing init, digest, update and final methods but not the finup method. Add a test for this one too. While doing this, make sure we only run the partial tests once with the digest tests and skip them with the final and finup tests since they are the same. Signed-off-by:
-
Hadar Gat authored
finup() operation was incorrect, padding was missing. Fix by setting the ccree HW to enable padding. Signed-off-by:
Hadar Gat <hadar.gat@arm.com> [ gilad@benyossef.com: refactored for better code sharing ] Signed-off-by:
-
Eric Biggers authored
Some crypto API users allocating a tfm with crypto_alloc_$FOO() are also specifying the type flags for $FOO, e.g. crypto_alloc_shash() with CRYPTO_ALG_TYPE_SHASH. But, that's redundant since the crypto API will override any specified type flag/mask with the correct ones. So, remove the unneeded flags. This patch shouldn't change any actual behavior. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
Some skcipher algorithms set .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER. But this is redundant with the C structure type ('struct skcipher_alg'), and crypto_register_skcipher() already sets the type flag automatically, clearing any type flag that was already there. Apparently the useless assignment has just been copy+pasted around. So, remove the useless assignment from all the skcipher algorithms. This patch shouldn't change any actual behavior. Signed-off-by: -
Eric Biggers authored
Some aead algorithms set .cra_flags = CRYPTO_ALG_TYPE_AEAD. But this is redundant with the C structure type ('struct aead_alg'), and crypto_register_aead() already sets the type flag automatically, clearing any type flag that was already there. Apparently the useless assignment has just been copy+pasted around. So, remove the useless assignment from all the aead algorithms. This patch shouldn't change any actual behavior. Signed-off-by: -
Eric Biggers authored
Some ahash algorithms set .cra_type = &crypto_ahash_type. But this is redundant with the C structure type ('struct ahash_alg'), and crypto_register_ahash() already sets the .cra_type automatically. Apparently the useless assignment has just been copy+pasted around. So, remove the useless assignment from all the ahash algorithms. This patch shouldn't change any actual behavior. Signed-off-by: -
Eric Biggers authored
Many ahash algorithms set .cra_flags = CRYPTO_ALG_TYPE_AHASH. But this is redundant with the C structure type ('struct ahash_alg'), and crypto_register_ahash() already sets the type flag automatically, clearing any type flag that was already there. Apparently the useless assignment has just been copy+pasted around. So, remove the useless assignment from all the ahash algorithms. This patch shouldn't change any actual behavior. Signed-off-by: -
Eric Biggers authored
Many shash algorithms set .cra_flags = CRYPTO_ALG_TYPE_SHASH. But this is redundant with the C structure type ('struct shash_alg'), and crypto_register_shash() already sets the type flag automatically, clearing any type flag that was already there. Apparently the useless assignment has just been copy+pasted around. So, remove the useless assignment from all the shash algorithms. This patch shouldn't change any actual behavior. Signed-off-by: -
Eric Biggers authored
With all the crypto modules enabled on x86, and with a CPU that supports AVX-2 but not SHA-NI instructions (e.g. Haswell, Broadwell, Skylake), the "multibuffer" implementations of SHA-1, SHA-256, and SHA-512 are the highest priority. However, these implementations only perform well when many hash requests are being submitted concurrently, filling all 8 AVX-2 lanes. Otherwise, they are incredibly slow, as they waste time waiting for more requests to arrive before proceeding to execute each request. For example, here are the speeds I see hashing 4096-byte buffers with a single thread on a Haswell-based processor: generic avx2 mb (multibuffer) ------- -------- ---------------- sha1 602 MB/s 997 MB/s 0.61 MB/s sha256 228 MB/s 412 MB/s 0.61 MB/s sha512 312 MB/s 559 MB/s 0.61 MB/s So, the multibuffer implementation is 500 to 1000 times slower than the other implementations. Note that with smaller buffers or more update()s per digest, the difference would be even greater. I believe the vast majority of people are in the boat where the multibuffer code is much slower, and only a small minority are doing the highly parallel, hashing-intensive, latency-flexible workloads (maybe IPsec on servers?) where the multibuffer code may be beneficial. Yet, people often aren't familiar with all the crypto config options and so the multibuffer code may inadvertently be built into the kernel. Also the multibuffer code apparently hasn't been very well tested, seeing as it was sometimes computing the wrong SHA-256 digest. So, let's make the multibuffer algorithms low priority. Users who want to use them can either request them explicitly by driver name, or use NETLINK_CRYPTO (crypto_user) to increase their priority at runtime. Signed-off-by: -
Eric Biggers authored
sha512-generic and sha384-generic had a cra_priority of 0, so it wasn't possible to have a lower priority SHA-512 or SHA-384 implementation, as is desired for sha512_mb which is only useful under certain workloads and is otherwise extremely slow. Change them to priority 100, which is the priority used for many of the other generic algorithms. Signed-off-by:
-
Eric Biggers authored
sha256-generic and sha224-generic had a cra_priority of 0, so it wasn't possible to have a lower priority SHA-256 or SHA-224 implementation, as is desired for sha256_mb which is only useful under certain workloads and is otherwise extremely slow. Change them to priority 100, which is the priority used for many of the other generic algorithms. Signed-off-by:
-
Eric Biggers authored
sha1-generic had a cra_priority of 0, so it wasn't possible to have a lower priority SHA-1 implementation, as is desired for sha1_mb which is only useful under certain workloads and is otherwise extremely slow. Change it to priority 100, which is the priority used for many of the other generic algorithms. Signed-off-by:
-
