- 09 Jan, 2020 22 commits
-
-
Eric Biggers authored
Currently, ahash spawns are initialized by using ahash_attr_alg() or crypto_find_alg() to look up the ahash algorithm, then calling crypto_init_ahash_spawn(). This is different from how skcipher, aead, and akcipher spawns are initialized (they use crypto_grab_*()), and for no good reason. This difference introduces unnecessary complexity. The crypto_grab_*() functions used to have some problems, like not holding a reference to the algorithm and requiring the caller to initialize spawn->base.inst. But those problems are fixed now. So, let's introduce crypto_grab_ahash() so that we can convert all templates to the same way of initializing their spawns. Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Eric Biggers authored
Currently, shash spawns are initialized by using shash_attr_alg() or crypto_alg_mod_lookup() to look up the shash algorithm, then calling crypto_init_shash_spawn(). This is different from how skcipher, aead, and akcipher spawns are initialized (they use crypto_grab_*()), and for no good reason. This difference introduces unnecessary complexity. The crypto_grab_*() functions used to have some problems, like not holding a reference to the algorithm and requiring the caller to initialize spawn->base.inst. But those problems are fixed now. So, let's introduce crypto_grab_shash() so that we can convert all templates to the same way of initializing their spawns. Signed-off-by:
-
Eric Biggers authored
Currently, crypto_spawn::inst is first used temporarily to pass the instance to crypto_grab_spawn(). Then crypto_init_spawn() overwrites it with crypto_spawn::next, which shares the same union. Finally, crypto_spawn::inst is set again when the instance is registered. Make this less convoluted by just passing the instance as an argument to crypto_grab_spawn() instead. Signed-off-by:
-
Eric Biggers authored
Initializing a crypto_akcipher_spawn currently requires: 1. Set spawn->base.inst to point to the instance. 2. Call crypto_grab_akcipher(). But there's no reason for these steps to be separate, and in fact this unneeded complication has caused at least one bug, the one fixed by commit 6db43410 ("crypto: adiantum - initialize crypto_spawn::inst") So just make crypto_grab_akcipher() take the instance as an argument. To keep the function call from getting too unwieldy due to this extra argument, also introduce a 'mask' variable into pkcs1pad_create(). Signed-off-by:
-
Eric Biggers authored
Initializing a crypto_aead_spawn currently requires: 1. Set spawn->base.inst to point to the instance. 2. Call crypto_grab_aead(). But there's no reason for these steps to be separate, and in fact this unneeded complication has caused at least one bug, the one fixed by commit 6db43410 ("crypto: adiantum - initialize crypto_spawn::inst") So just make crypto_grab_aead() take the instance as an argument. To keep the function calls from getting too unwieldy due to this extra argument, also introduce a 'mask' variable into the affected places which weren't already using one. Signed-off-by:
-
Eric Biggers authored
Initializing a crypto_skcipher_spawn currently requires: 1. Set spawn->base.inst to point to the instance. 2. Call crypto_grab_skcipher(). But there's no reason for these steps to be separate, and in fact this unneeded complication has caused at least one bug, the one fixed by commit 6db43410 ("crypto: adiantum - initialize crypto_spawn::inst") So just make crypto_grab_skcipher() take the instance as an argument. To keep the function calls from getting too unwieldy due to this extra argument, also introduce a 'mask' variable into the affected places which weren't already using one. Signed-off-by:
-
Eric Biggers authored
Define struct ahash_instance in a way analogous to struct skcipher_instance, struct aead_instance, and struct akcipher_instance, where the struct is defined to include both the algorithm structure at the beginning and the additional crypto_instance fields at the end. This is needed to allow allocating ahash instances directly using kzalloc(sizeof(*inst) + sizeof(*ictx), ...) in the same way as skcipher, aead, and akcipher instances. In turn, that's needed to make spawns be initialized in a consistent way everywhere. Also take advantage of the addition of the base instance to struct ahash_instance by simplifying the ahash_crypto_instance() and ahash_instance() functions. Signed-off-by:
-
Eric Biggers authored
Define struct shash_instance in a way analogous to struct skcipher_instance, struct aead_instance, and struct akcipher_instance, where the struct is defined to include both the algorithm structure at the beginning and the additional crypto_instance fields at the end. This is needed to allow allocating shash instances directly using kzalloc(sizeof(*inst) + sizeof(*ictx), ...) in the same way as skcipher, aead, and akcipher instances. In turn, that's needed to make spawns be initialized in a consistent way everywhere. Also take advantage of the addition of the base instance to struct shash_instance by simplifying the shash_crypto_instance() and shash_instance() functions. Signed-off-by:
-
Eric Biggers authored
To allow further simplifying template ->create() functions, make crypto_grab_spawn() handle an ERR_PTR() name by passing back the error. For most templates, this will allow the result of crypto_attr_alg_name() to be passed directly to crypto_grab_*(), rather than first having to assign it to a variable [where it can then potentially be misused, as it was in the rfc7539 template prior to commit 5e27f38f ("crypto: chacha20poly1305 - set cra_name correctly")] and check it for error. Signed-off-by:
-
Eric Biggers authored
Make crypto_drop_spawn() do nothing when the spawn hasn't been initialized with an algorithm yet. This will allow simplifying error handling in all the template ->create() functions, since on error they will be able to just call their usual "free instance" function, rather than having to handle dropping just the spawns that have been initialized so far. This does assume the spawn starts out zero-filled, but that's always the case since instances are allocated with kzalloc(). And some other code already assumes this anyway. Signed-off-by:
-
Gary R Hook authored
Remove Gary R Hook as CCP maintainer. Signed-off-by: -
Christian Lamparter authored
The driver should use GFP_KERNEL for the bigger allocation during the driver's crypto4xx_probe() and not GFP_ATOMIC in my opinion. Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Christian Lamparter authored
With recent kernels (>5.2), the driver fails to probe, as the allocation of the driver's scatter buffer fails with -ENOMEM. This happens in crypto4xx_build_sdr(). Where the driver tries to get 512KiB (=PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD) of continuous memory. This big chunk is by design, since the driver uses this circumstance in the crypto4xx_copy_pkt_to_dst() to its advantage: "all scatter-buffers are all neatly organized in one big continuous ringbuffer; So scatterwalk_map_and_copy() can be instructed to copy a range of buffers in one go." The PowerPC arch does not have support for DMA_CMA. Hence, this patch reorganizes the order in which the memory allocations are done. Since the driver itself is responsible for some of the issues. Signed-off-by:
-
Eric Biggers authored
The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the ->setkey() functions provide more information about errors. But these flags weren't actually being used or tested, and in many cases they weren't being set correctly anyway. So they've now been removed. Also, if someone ever actually needs to start better distinguishing ->setkey() errors (which is somewhat unlikely, as this has been unneeded for a long time), we'd be much better off just defining different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that propagates these flags around. Signed-off-by:
-
Eric Biggers authored
The CRYPTO_TFM_RES_WEAK_KEY flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. There are also no tests that verify that all algorithms actually set (or don't set) it correctly. This is also the last remaining CRYPTO_TFM_RES_* flag, which means that it's the only thing still needing all the boilerplate code which propagates these flags around from child => parent tfms. And if someone ever needs to distinguish this error in the future (which is somewhat unlikely, as it's been unneeded for a long time), it would be much better to just define a new return value like -EKEYREJECTED. That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by:
-
Eric Biggers authored
The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to make the ->setkey() functions provide more information about errors. However, no one actually checks for this flag, which makes it pointless. Also, many algorithms fail to set this flag when given a bad length key. Reviewing just the generic implementations, this is the case for aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309, rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably many more in arch/*/crypto/ and drivers/crypto/. Some algorithms can even set this flag when the key is the correct length. For example, authenc and authencesn set it when the key payload is malformed in any way (not just a bad length), the atmel-sha and ccree drivers can set it if a memory allocation fails, and the chelsio driver sets it for bad auth tag lengths, not just bad key lengths. So even if someone actually wanted to start checking this flag (which seems unlikely, since it's been unused for a long time), there would be a lot of work needed to get it working correctly. But it would probably be much better to go back to the drawing board and just define different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove this flag. Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
-
Eric Biggers authored
The flag CRYPTO_TFM_RES_BAD_BLOCK_LEN is never checked for, and it's only set by one driver. And even that single driver's use is wrong because the driver is setting the flag from ->encrypt() and ->decrypt() with no locking, which is unsafe because ->encrypt() and ->decrypt() can be executed by many threads in parallel on the same tfm. Just remove this flag. Signed-off-by:
-
Eric Biggers authored
The tfm result flags CRYPTO_TFM_RES_BAD_KEY_SCHED and CRYPTO_TFM_RES_BAD_FLAGS are never used, so remove them. Signed-off-by:
-
Eric Biggers authored
HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated any error as a "bad key length" error. Fix it to correctly propagate the -ENOMEM error code and not set any tfm result flags. Fixes: 81d8750b ("crypto: atmel-sha - add support to hmac(shaX)") Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
-
Eric Biggers authored
->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1. Fixes: a21eb94f ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
Lars Persson <lars.persson@axis.com> Signed-off-by:
-
Eric Biggers authored
The chelsio crypto driver is casting 'struct crypto_aead' directly to 'struct crypto_tfm', which is incorrect because the crypto_tfm isn't the first field of 'struct crypto_aead'. Consequently, the calls to crypto_tfm_set_flags() are modifying some other field in the struct. Also, the driver is setting CRYPTO_TFM_RES_BAD_KEY_LEN in ->setauthsize(), not just in ->setkey(). This is incorrect since this flag is for bad key lengths, not for bad authentication tag lengths. Fix these bugs by removing the broken crypto_tfm_set_flags() calls from ->setauthsize() and by fixing them in ->setkey(). Fixes: 324429d7 ("chcr: Support for Chelsio's Crypto Hardware") Cc: <stable@vger.kernel.org> # v4.9+ Cc: Atul Gupta <atul.gupta@chelsio.com> Signed-off-by:
-
Eric Biggers authored
skcipher_walk_aead() is unused and is identical to skcipher_walk_aead_encrypt(), so remove it. Signed-off-by:
-
- 04 Jan, 2020 4 commits
-
-
Rijo Thomas authored
Update tee.txt with AMD-TEE driver details. The driver is written to communicate with AMD's TEE. Acked-by:
Jens Wiklander <jens.wiklander@linaro.org> Co-developed-by:
Devaraj Rangasamy <Devaraj.Rangasamy@amd.com> Signed-off-by:
Rijo Thomas <Rijo-john.Thomas@amd.com> Reviewed-by:
Gary R Hook <gary.hook@amd.com> Signed-off-by:
-
Rijo Thomas authored
The AMD-TEE driver should check if TEE is available before registering itself with TEE subsystem. This ensures that there is a TEE which the driver can talk to before proceeding with tee device node allocation. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Acked-by:
-
Rijo Thomas authored
Adds AMD-TEE driver. * targets AMD APUs which has AMD Secure Processor with software-based Trusted Execution Environment (TEE) support * registers with TEE subsystem * defines tee_driver_ops function callbacks * kernel allocated memory is used as shared memory between normal world and secure world. * acts as REE (Rich Execution Environment) communication agent, which uses the services of AMD Secure Processor driver to submit commands for processing in TEE environment Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Tom Lendacky <thomas.lendacky@amd.com> Acked-by:
-
Rijo Thomas authored
Allow compilation of tee subsystem for AMD's CPUs which have a dedicated AMD Secure Processor for Trusted Execution Environment (TEE). Acked-by:
-
- 27 Dec, 2019 14 commits
-
-
Eneas U de Queiroz authored
Allow the user to choose whether to build support for all algorithms (default), hashes-only, or skciphers-only. The QCE engine does not appear to scale as well as the CPU to handle multiple crypto requests. While the ipq40xx chips have 4-core CPUs, the QCE handles only 2 requests in parallel. Ipsec throughput seems to improve when disabling either family of algorithms, sharing the load with the CPU. Enabling skciphers-only appears to work best. Signed-off-by:
Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by:
-
Eneas U de Queiroz authored
Adjust cra_flags to add CRYPTO_NEED_FALLBACK only for AES ciphers, where AES-192 is not handled by the qce hardware, and don't allocate & free the fallback skcipher for other algorithms. Signed-off-by:
-
Eneas U de Queiroz authored
Update the IV after the completion of each cipher operation. Signed-off-by:
-
Eneas U de Queiroz authored
When ctr-aes-qce is used for gcm-mode, an extra sg entry for the authentication tag is present, causing trouble when the qce driver prepares the dst-results sg table for dma. It computes the number of entries needed with sg_nents_for_len, leaving out the tag entry. Then it creates a sg table with that number plus one, used to store a result buffer. When copying the sg table, there's no limit to the number of entries copied, so the extra slot is filled with the authentication tag sg. When the driver tries to add the result sg, the list is full, and it returns EINVAL. By limiting the number of sg entries copied to the dest table, the slot for the result buffer is guaranteed to be unused. Signed-off-by:
-
Eneas U de Queiroz authored
XTS-mode uses two keys, so the keysizes should be doubled in skcipher_def, and halved when checking if it is AES-128/192/256. Signed-off-by:
-
Eneas U de Queiroz authored
Set blocksize of ctr-aes-qce to 1, so it can operate as a stream cipher, adding the definition for chucksize instead, where the underlying block size belongs. Signed-off-by:
-
Herbert Xu authored
This patch introduces the skcipher_ialg_simple helper which fetches the crypto_alg structure from a simple skcipher instance's spawn. This allows us to remove the third argument from the function skcipher_alloc_instance_simple. In doing so the reference count to the algorithm is now maintained by the Crypto API and the caller no longer needs to drop the alg refcount. Signed-off-by: -
Vinay Kumar Yadav authored
Freed work request skbs when connection terminates. enqueue_wr()/ dequeue_wr() is shared between softirq and application contexts, should be protected by socket lock. Moved dequeue_wr() to appropriate file. Signed-off-by:
Vinay Kumar Yadav <vinay.yadav@chelsio.com> Signed-off-by:
-
Vinay Kumar Yadav authored
Added support to set 256 bit key to the hardware from setsockopt for AES256-GCM based ciphers. Signed-off-by:
-
Adam Ford authored
The i.MX8M Mini uses the same crypto engine as the i.MX8MQ, but the driver is restricting the check to just the i.MX8MQ. This patch expands the check for either i.MX8MQ or i.MX8MM. Signed-off-by:
Adam Ford <aford173@gmail.com> Tested-by:
Iuliana Prodan <iuliana.prodan@nxp.com> Reviewed-by:
-
Herbert Xu authored
This patch changes crypto_grab_spawn to retain the reference count on the algorithm. This is because the caller needs to access the algorithm parameters and without the reference count the algorithm can be freed at any time. The reference count will be subsequently dropped by the crypto API once the instance has been registered. The helper crypto_drop_spawn will also conditionally drop the reference count depending on whether it has been registered. Note that the code is actually added to crypto_init_spawn. However, unless the caller activates this by setting spawn->dropref beforehand then nothing happens. The only caller that sets dropref is currently crypto_grab_spawn. Once all legacy users of crypto_init_spawn disappear, then we can kill the dropref flag. Internally each instance will maintain a list of its spawns prior to registration. This memory used by this list is shared with other fields that are only used after registration. In order for this to work a new flag spawn->registered is added to indicate whether spawn->inst can be used. Fixes: d6ef2f19 ("crypto: api - Add crypto_grab_spawn primitive") Signed-off-by:
-
Ben Dooks (Codethink) authored
The sun4i_ss_pm_ops is not referenced outside the driver except via a pointer, so make it static to avoid the following warning: drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c:276:25: warning: symbol 'sun4i_ss_pm_ops' was not declared. Should it be static? Signed-off-by:
Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
-
