- 30 May, 2019 28 commits
-
-
Sascha Hauer authored
The CAAM driver defines its own debug() macro, but it is unused. Remove it. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Sascha Hauer authored
Since eaed71a4 ("crypto: caam - add ecb(*) support") the IV can be NULL, so only dump it when it's non NULL as designated by the ivsize variable. Fixes: eaed71a4 ("crypto: caam - add ecb(*) support") Signed-off-by:
-
Herbert Xu authored
This patch changes multiple uses of u32s to dma_addr_t where the physical address is used. This fixes COMPILE_TEST errors on 64-bit platforms. Signed-off-by: -
Christophe Leroy authored
This patch drops the license text and replaces it with an SPDX-License-Identifier tag. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Christophe Leroy authored
This patch rewrites has_ftr_sec1() using IS_ENABLED() instead of #ifdefs Signed-off-by:
-
Christophe Leroy authored
There is no other file using talitos_submit in the kernel tree, so it doesn't need to be exported nor made global. This reverts commit 865d5061. Signed-off-by:
-
Christophe Leroy authored
This driver is working well in 'simple cases', but as soon as more exotic SG lists are provided (dst different from src, auth part not in a single SG fragment, ...) there are wrong results, overruns, etc ... This patch cleans up the AEAD processing by: - Simplifying the location of 'out of line' ICV - Never using 'out of line' ICV on encryp - Always using 'out of line' ICV on decrypt - Forcing the generation of a SG table on decrypt Signed-off-by:
-
Christophe Leroy authored
The MPC885 reference manual states: SEC Lite-initiated 8xx writes can occur only on 32-bit-word boundaries, but reads can occur on any byte boundary. Writing back a header read from a non-32-bit-word boundary will yield unpredictable results. In order to ensure that, cra_alignmask is set to 3 for SEC1. Signed-off-by:
-
Christophe Leroy authored
The driver assumes that the ICV is as a single piece in the last element of the scatterlist. This assumption is wrong. This patch ensures that the ICV is properly handled regardless of the scatterlist layout. Fixes: 9c4a7965 ("crypto: talitos - Freescale integrated security engine (SEC) driver") Signed-off-by:
-
Christophe Leroy authored
In that mode, hardware ICV verification is not supported. Signed-off-by:
-
Christophe Leroy authored
For decrypt, req->cryptlen includes the size of the authentication part while all functions of the driver expect cryptlen to be the size of the encrypted data. As it is not expected to change req->cryptlen, this patch implements local calculation of cryptlen. Signed-off-by:
-
Christophe Leroy authored
ECB's ivsize must be 0. Signed-off-by:
-
Christophe Leroy authored
When data size is not a multiple of the alg's block size, the SEC generates an error interrupt and dumps the registers. And for NULL size, the SEC does just nothing and the interrupt is awaited forever. This patch ensures the data size is correct before submitting the request to the SEC engine. Signed-off-by:
-
Christophe Leroy authored
CTR has a blocksize of 1. Signed-off-by:
-
Christophe Leroy authored
Although the HW accepts any size and silently truncates it to the correct length, the extra tests expects EINVAL to be returned when the key size is not valid. Signed-off-by:
-
Christophe Leroy authored
SEC1 doesn't support SHA384/512, so it doesn't require longer keys. This patch reduces the max key size when the driver is built for SEC1 only. Signed-off-by:
-
Christophe Leroy authored
The talitos driver has two ways to perform AEAD depending on the HW capability. Some HW support both. It is needed to give them different names to distingish which one it is for instance when a test fails. Signed-off-by:
-
Eric Biggers authored
Remove the crypto_tfm_in_queue() function, which is unused. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
Remove the unnecessary constant CRYPTO_ALG_TYPE_DIGEST, which has the same value as CRYPTO_ALG_TYPE_HASH. Signed-off-by:
-
Eric Biggers authored
kcrypto_wq is only used by cryptd, so move it into cryptd.c and change the workqueue name from "crypto" to "cryptd". Signed-off-by:
-
Eric Biggers authored
There's no reason for users to select CONFIG_CRYPTO_GF128MUL, since it's just some helper functions, and algorithms that need it select it. Remove the prompt string so that it's not shown to users. Signed-off-by:
-
Eric Biggers authored
echainiv is the only algorithm or template in the crypto API that is enabled by default. But there doesn't seem to be a good reason for it. And it pulls in a lot of stuff as dependencies, like AEAD support and a "NIST SP800-90A DRBG" including HMAC-SHA256. The commit which made it default 'm', commit 3491244c ("crypto: echainiv - Set Kconfig default to m"), mentioned that it's needed for IPsec. However, later commit 32b6170c ("ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV") made the IPsec kconfig options select it. So, remove the 'default m'. Signed-off-by:
-
Eric Biggers authored
The "cryptomgr" module is required for templates to be used. Many templates select it, but others don't. Make all templates select it. Signed-off-by:
-
Eric Biggers authored
The crypto self-tests are part of the "cryptomgr" module, which can technically be disabled (though it rarely is). If you do so, currently you can still enable CRYPTO_MANAGER_EXTRA_TESTS, which doesn't make sense since in that case testmgr.c isn't compiled at all. Fix it by making it CRYPTO_MANAGER_EXTRA_TESTS depend on CRYPTO_MANAGER2, like CRYPTO_MANAGER_DISABLE_TESTS already does. Fixes: 5b2706a4 ("crypto: testmgr - introduce CONFIG_CRYPTO_MANAGER_EXTRA_TESTS") Signed-off-by:
-
Eric Biggers authored
On PowerPC with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, there is sometimes a crash in generate_random_aead_testvec(). The problem is that the generated test vectors use data lengths of up to about 2 * PAGE_SIZE, which is 128 KiB on PowerPC; however, the data length fields in the test vectors are 'unsigned short', so the lengths get truncated. Fix this by changing the relevant fields to 'unsigned int'. Fixes: 40153b10 ("crypto: testmgr - fuzz AEADs against their generic implementation") Signed-off-by:
-
Eric Biggers authored
Convert the VMX implementations of AES-CBC, AES-CTR, and AES-XTS from the deprecated "blkcipher" API to the "skcipher" API. As part of this, I moved the skcipher_request for the fallback algorithm off the stack and into the request context of the parent algorithm. I tested this in a PowerPC VM with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Eric Biggers authored
Remove the boilerplate license text and replace it with the equivalent SPDX license identifier. Signed-off-by:
-
Neil Armstrong authored
Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
- 23 May, 2019 12 commits
-
-
Christian Lamparter authored
The hardware automatically zero pads incomplete block ciphers blocks without raising any errors. This is a screw-up. This was noticed by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS tests that sent a incomplete blocks and expect them to fail. This fixes: cbc-aes-ppc4xx encryption unexpectedly succeeded on test vector "random: len=2409 klen=32"; expected_error=-22, cfg="random: may_sleep use_digest src_divs=[96.90%@+2295, 2.34%@+4066, 0.32%@alignmask+12, 0.34%@+4087, 0.9%@alignmask+1787, 0.1%@+3767] iv_offset=6" ecb-aes-ppc4xx encryption unexpectedly succeeded on test vector "random: len=1011 klen=32"; expected_error=-22, cfg="random: may_sleep use_digest src_divs=[100.0%@alignmask+20] dst_divs=[3.12%@+3001, 96.88%@+4070]" Cc: Eric Biggers <ebiggers@kernel.org> Cc: stable@vger.kernel.org [4.19, 5.0 and 5.1] Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Christian Lamparter authored
While the hardware consider them to be blockciphers, the reference implementation defines them as streamciphers. Do the right thing and set the blocksize to 1. This was found by CONFIG_CRYPTO_MANAGER_EXTRA_TESTS. This fixes the following issues: skcipher: blocksize for ofb-aes-ppc4xx (16) doesn't match generic impl (1) skcipher: blocksize for cfb-aes-ppc4xx (16) doesn't match generic impl (1) Cc: Eric Biggers <ebiggers@kernel.org> Cc: stable@vger.kernel.org Fixes: f2a13e7c ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads") Signed-off-by:
-
Christian Lamparter authored
This patch fixes a issue with crypto4xx's ctr(aes) that was discovered by libcapi's kcapi-enc-test.sh test. The some of the ctr(aes) encryptions test were failing on the non-power-of-two test: kcapi-enc - Error: encryption failed with error 0 kcapi-enc - Error: decryption failed with error 0 [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits): original file (1d100e..cc96184c) and generated file (e3b0c442..1b7852b855) [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits) (openssl generated CT): original file (e3b0..5) and generated file (3..8e) [PASSED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (128 bits) (openssl generated PT) [FAILED: 32-bit - 5.1.0-rc1+] 15 bytes: STDIN / STDOUT enc test (password): original file (1d1..84c) and generated file (e3b..852b855) But the 16, 32, 512, 65536 tests always worked. Thankfully, this isn't a hidden hardware problem like previously, instead this turned out to be a copy and paste issue. With this patch, all the tests are passing with and kcapi-enc-test.sh gives crypto4xx's a clean bill of health: "Number of failures: 0" :). Cc: stable@vger.kernel.org Fixes: 98e87e3d ("crypto: crypto4xx - add aes-ctr support") Fixes: f2a13e7c ("crypto: crypto4xx - enable AES RFC3686, ECB, CFB and OFB offloads") Signed-off-by:
-
Sascha Hauer authored
For encryption the destination pointer was still mapped, so the hex dump may be wrong. The IV still contained the input IV while printing instead of the output IV as intended. For decryption the destination pointer was still mapped, so the hex dump may be wrong. The IV dump was correct. Do the hex dumps consistenly after the buffers have been unmapped and in case of IV copied to their final destination. Signed-off-by:
-
Christophe Leroy authored
Selftests report the following: [ 2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 2.995377] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41 [ 3.032673] alg: skcipher: cbc-des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 3.043185] 00000000: fe dc ba 98 76 54 32 10 [ 3.063238] alg: skcipher: cbc-3des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place" [ 3.073818] 00000000: 7d 33 88 93 0f 93 b2 42 This above dumps show that the actual output IV is indeed the input IV. This is due to the IV not being copied back into the request. This patch fixes that. Signed-off-by:
-
Hook, Gary authored
Crypto self-tests reveal an error: alg: skcipher: cbc-des3-ccp encryption test failed (wrong output IV) on test vector 0, cfg="in-place" The offset value should not be recomputed when retrieving the context. Also, a code path exists which makes decisions based on older (version 3) hardware; a v3 device deosn't support 3DES so remove this check. Fixes: 990672d4 ('crypto: ccp - Enable 3DES function on v5 CCPs') Signed-off-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
-
Hook, Gary authored
Updated testmgr will exhibit this error message when loading the ccp-crypto module: alg: skcipher: cfb-aes-ccp encryption failed with err -22 on test vector 3, cfg="in-place" Update the CCP crypto driver to correctly treat CFB as a streaming mode cipher (instead of block mode). Update the configuration for CFB to specify the block size as a single byte; Fixes: 2b789435 ('crypto: ccp - CCP AES crypto API support') Signed-off-by:
-
Hook, Gary authored
CFB mode should be treated as a stream cipher, not block. Fixes: 63b94509 ('crypto: ccp - CCP device driver and interface support') Signed-off-by:
-
YueHaibing authored
Fix sparse warning: arch/arm/crypto/sha512-glue.c:40:5: warning: symbol 'sha512_arm_final' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
Stephan Mueller authored
FIPS 140-2 section 4.9.2 requires a continuous self test of the noise source. Up to kernel 4.8 drivers/char/random.c provided this continuous self test. Afterwards it was moved to a location that is inconsistent with the FIPS 140-2 requirements. The relevant patch was e192be9d . Thus, the FIPS 140-2 CTRNG is added to the DRBG when it obtains the seed. This patch resurrects the function drbg_fips_continous_test that existed some time ago and applies it to the noise sources. The patch that removed the drbg_fips_continous_test was b3614763 . The Jitter RNG implements its own FIPS 140-2 self test and thus does not need to be subjected to the test in the DRBG. The patch contains a tiny fix to ensure proper zeroization in case of an error during the Jitter RNG data gathering. Signed-off-by:
Stephan Mueller <smueller@chronox.de> Reviewed-by:
Yann Droneaud <ydroneaud@opteya.com> Signed-off-by:
-
Horia Geantă authored
Currently there is a mismatch b/w the ICID (Isolation Context ID) used for DMA mapping keys and ICID used for accessing them. -keys are DMA mapped using a job ring device, thus a job ring ICID -keys are accessed from descriptors enqueued via Queue Interface, thus using QI ICID [Note: ICIDs of JRs, QI are configured by U-boot / other entity by: -fixing up the corresponding job ring and controller DT nodes -setting up corresponding caam ICID registers] In order to avoid IOMMU faults, DMA map the key using the controller device instead of a job ring device. Signed-off-by:
-
Horia Geantă authored
When IOMMU is enabled, iova -> phys address translation should be performed using iommu_ops, not dma_to_phys(). Signed-off-by:
-
