- 20 Oct, 2015 29 commits
-
-
Russell King authored
Use relaxed IO accessors where appropriate. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
The kernel's coding style suggests that closing braces for initialisers should not be aligned to the open brace column. The CodingStyle doc shows how this should be done. Remove the additional tab. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Avoid exporting lots of state by only exporting what we really require, which is the buffer containing the set of pending bytes to be hashed, number of pending bytes, the context buffer, and the function pointer state. This reduces down the exported state size to 216 bytes from 576 bytes. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
caam does not properly calculate the size of the retained state when non-block aligned hashes are requested - it uses the wrong buffer sizes, which results in errors such as: caam_jr 2102000.jr1: 40000501: DECO: desc idx 5: SGT Length Error. The descriptor is trying to read more data than is contained in the SGT table. We end up here with: in_len 0x46 blocksize 0x40 last_bufsize 0x0 next_bufsize 0x6 to_hash 0x40 ctx_len 0x28 nbytes 0x20 which results in a job descriptor of: jobdesc@889: ed03d918: b0861c08 3daa0080 f1400000 3d03d938 jobdesc@889: ed03d928: 00000068 f8400000 3cde2a40 00000028 where the word at 0xed03d928 is the expected data size (0x68), and a scatterlist containing: sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000 sg@892: ed03d948: 00000000 3d03d100 00000006 00000000 sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000 0x68 comes from 0x28 (the context size) plus the "in_len" rounded down to a block size (0x40). in_len comes from 0x26 bytes of unhashed data from the previous operation, plus the 0x20 bytes from the latest operation. The fixed version would create: sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000 sg@892: ed03d948: 00000000 3d03d100 00000026 00000000 sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000 which replaces the 0x06 length with the correct 0x26 bytes of previously unhashed data. This fixes a previous commit which erroneously "fixed" this due to a DMA-API bug report; that commit indicates that the bug was caused via a test_ahash_pnum() function in the tcrypt module. No such function has ever existed in the mainline kernel. Given that the change in this commit has been tested with DMA API debug enabled and shows no issue, I can only conclude that test_ahash_pnum() was triggering that bad behaviour by CAAM. Fixes: 7d5196ab ("crypto: caam - Correct DMA unmap size in ahash_update_ctx()") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
When exporting and importing the hash state, we will only export and import into hashes which share the same struct crypto_ahash pointer. (See hash_accept->af_alg_accept->hash_accept_parent.) This means that saving the caam_hash_ctx structure on export, and restoring it on import is a waste of resources. So, remove this code. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Print the errno code when hash registration fails, so we know why the failure occurred. This aids debugging. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Boris Brezillon authored
To: Boris Brezillon <boris.brezillon@free-electrons.com>,Arnaud Ebalard <arno@natisbad.org>,Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,Jason Cooper <jason@lakedaemon.net> The local chain variable is not cleaned up if an error occurs in the middle of DMA chain creation. Fix that by dropping the local chain variable and using the dreq->chain field which will be cleaned up by mv_cesa_dma_cleanup() in case of errors. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
When adding the software padding, this must be done using the first/mid fragment mode, and any subsequent operation needs to be a mid-fragment. Fix this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Rearrange the last request handling for hashes which require software padding. We prepare the padding to be appended, and then append as much of the padding to any existing data that's already queued up, adding an operation block and launching the operation. Any remainder is then appended as a separate operation. This ensures that the hardware only ever sees multiples of the hash block size to be operated on for software padded hashes, thus ensuring that the engine always indicates that it has finished the calculation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Rearrange the last request handling for hardware finished hashes by moving the generation of the fragment operation into this path. This results in a simplified sequence to handle this case, and allows us to move the software padded case further down into the function. Add comments describing these parts. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Move the test for the last request out of mv_cesa_ahash_dma_last_req() to its caller, and move the mv_cesa_dma_add_frag() down into this function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Avoid adding the final operation within the loop, but instead add it outside. We combine this with the handling for the no-data case. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
When we process the last request of data, and the request contains user data, the loop in mv_cesa_ahash_dma_req_init() marks the first data size as being iter.base.op_len which does not include the size of the cache data. This means we end up hashing an insufficient amount of data. Fix this by always including the cache size in the first operation length of any request. This has the effect that for a request containing no user data, iter.base.op_len === iter.src.op_offset === creq->cache_ptr As a result, we include one further change to use iter.base.op_len in the cache-but-no-user-data case to make the next change clearer. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Use the presence of the scatterlist to determine whether we should load any new user data to the engine. The following shall always be true at this point: iter.base.op_len == 0 === iter.src.sg In doing so, we can: 1. eliminate the test for iter.base.op_len inside the loop, which makes the loop operation more obvious and understandable. 2. move the operation generation for the cache-only case. This prepares the code for the next step in its transformation, and also uncovers a bug that will be fixed in the next patch. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Move the calls to mv_cesa_dma_add_frag() into the parent function, mv_cesa_ahash_dma_req_init(). This is in preparation to changing when we generate the operation blocks, as we need to avoid generating a block for a partial hash block at the end of the user data. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
If we add a template first-fragment operation, always update the template to be a mid-fragment. This ensures that mid-fragments always follow on from a first fragment in every case. This means we can move the first to mid-fragment update code out of mv_cesa_ahash_dma_add_data(). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Add a helper to add the fragment operation block followed by the DMA entry to launch the operation. Although at the moment this pattern only strictly appears at one site, two other sites can be factored as well by slightly changing the order in which the DMA operations are performed. This should be harmless as the only thing which matters is to have all the data loaded into SRAM prior to launching the operation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Multiple locations in the driver test the operation context fragment type, checking whether it is a first fragment or not. Introduce a mv_cesa_mac_op_is_first_frag() helper, which returns true if the fragment operation is for a first fragment. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
mv_cesa_get_op_cfg() does not write to its argument, it only reads. So, let's make it const. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Ensure that the template operation is fully initialised, otherwise we end up loading data from the kernel stack into the engines, which can upset the hash results. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
The endianness of the bit length used in the final stage depends on the endianness of the algorithm - md5 hashes need it to be in little endian format, whereas SHA hashes need it in big endian format. Use the previously added algorithm endianness flag to control this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Rather than determining whether we're using a MD5 hash by looking at the digest size, switch to a cleaner solution using a per-request flag initialised by the method type. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
Currently, we read/write the state in CPU endian, but on the final request, we convert its endian according to the requested algorithm. (md5 is little endian, SHA are big endian.) Always keep creq->state in CPU native endian format, and perform the necessary conversion when copying the hash to the result. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Russell King authored
There's an easier way to get at the hash transform - rather than using crypto_ahash_tfm(ahash), we can get it directly from req->base.tfm. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Herbert Xu authored
This patch adds the missing helper crypto_ahash_blocksize which returns the block size of an ahash algorithm. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Stephan Mueller authored
The patch fixes the analysis of the input data which contains an off by one. The issue is visible when the SGL contains one byte per SG entry. The code for checking for zero bytes does not operate on the data byte. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Tadeusz Struk authored
qat_crypto_get_instance_node function needs to handle situation when the first dev in the list is not started. Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Daniel Thompson authored
Currently this driver calls pm_runtime_get_sync() rampantly but never puts anything back. This makes it impossible for the device to autosuspend properly; it will remain fully active after the first use. Fix in the obvious way. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
LABBE Corentin authored
The define SHA1_DIGEST_LENGTH is not used anywhere, so remove it. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
- 15 Oct, 2015 8 commits
-
-
LABBE Corentin authored
Some array of const char are not set as const. This patch fix that. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
LABBE Corentin authored
Some array of const char are not set as const. This patch fix that. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
LABBE Corentin authored
SHA_MAX_STATE_SIZE is just the number of u32 word for SHA512. So replace the raw value "16" by their meaning (SHA512_DIGEST_SIZE / 4) Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Stephan Mueller authored
The testmanager code for symmetric ciphers is extended to allow verification of the IV after a cipher operation. In addition, test vectors for kw(aes) for encryption and decryption are added. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Stephan Mueller authored
Hook keywrap source code into Kconfig and Makefile Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Stephan Mueller authored
This patch implements the AES key wrapping as specified in NIST SP800-38F and RFC3394. The implementation covers key wrapping without padding. IV handling: The caller does not provide an IV for encryption, but must obtain the IV after encryption which would serve as the first semblock in the ciphertext structure defined by SP800-38F. Conversely, for decryption, the caller must provide the first semiblock of the data as the IV and the following blocks as ciphertext. The key wrapping is an authenticated decryption operation. The caller will receive EBADMSG during decryption if the authentication failed. Albeit the standards define the key wrapping for AES only, the template can be used with any other block cipher that has a block size of 16 bytes. During initialization of the template, that condition is checked. Any cipher not having a block size of 16 bytes will cause the initialization to fail. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Boris BREZILLON authored
The crypto drivers are supposed to update the IV passed to the crypto request before calling the completion callback. Test for the IV value before considering the test as successful. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
Daniel Thompson authored
Commit c6a97c42 ("hwrng: stm32 - add support for STM32 HW RNG") was inadequately tested (actually it was tested quite hard so incompetent would be a better description that inadequate) and does not compile on platforms with CONFIG_PM set. Fix this. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
- 14 Oct, 2015 3 commits
-
-
Sowmini Varadhan authored
On sparc, we see unaligned access messages on each modprobe[-r]: Kernel unaligned access at TPC[6ad9b4] pkcs7_verify [..] Kernel unaligned access at TPC[6a5484] crypto_shash_finup [..] Kernel unaligned access at TPC[6a5390] crypto_shash_update [..] Kernel unaligned access at TPC[10150308] sha1_sparc64_update [..] Kernel unaligned access at TPC[101501ac] __sha1_sparc64_update [..] These ware triggered by mod_verify_sig() invocations of pkcs_verify(), and are are being caused by an unaligned desc at (sha1, digest_size is 0x14) desc = digest + digest_size; To fix this, pkcs7_verify needs to make sure that desc is pointing at an aligned value past the digest_size, and kzalloc appropriately, taking alignment values into consideration. Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
LABBE Corentin authored
Using the devm_xxx() managed function to stripdown the error and remove code. In the same time, we replace request_mem_region/ioremap by the unified devm_ioremap_resource() function. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-
LABBE Corentin authored
Using the devm_xxx() managed function to stripdown the error and remove code. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-