aboutsummaryrefslogtreecommitdiff
path: root/drivers/crypto/inside-secure/safexcel_hash.c
AgeCommit message (Collapse)AuthorFilesLines
2020-09-25crypto: inside-secure - Reuse code in safexcel_hmac_alg_setkeyHerbert Xu1-14/+23
The code in the current implementation of safexcel_hmac_alg_setkey can be reused by safexcel_cipher. This patch does just that by renaming the previous safexcel_hmac_setkey to __safexcel_hmac_setkey. The now-shared safexcel_hmac_alg_setkey becomes safexcel_hmac_setkey and a new safexcel_hmac_alg_setkey has been added for use by ahash transforms. As a result safexcel_aead_setkey's stack frame has been reduced by about half in size, or about 512 bytes. Reported-by: kernel test robot <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-09-25crypto: inside-secure - Move ipad/opad into safexcel_contextHerbert Xu1-52/+54
As both safexcel_ahash_ctx and safexcel_cipher_ctx contain ipad and opad buffers this patch moves them into the common struct safexcel_context. It also adds a union so that they can be accessed in the appropriate endian without crazy casts. Signed-off-by: Herbert Xu <[email protected]>
2020-09-25crypto: inside-secure - Move priv pointer into safexcel_contextHerbert Xu1-9/+8
This patch moves the priv pointer into struct safexcel_context because both structs that extend safexcel_context have that pointer as well. Signed-off-by: Herbert Xu <[email protected]>
2020-09-04crypto: inside-secure - use kfree_sensitive()Denis Efremov1-2/+1
Use kfree_sensitive() instead of open-coding it. Signed-off-by: Denis Efremov <[email protected]> Acked-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-07-16crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORYMikulas Patocka1-0/+18
Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that allocate memory. drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c: sun8i_ce_cipher drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c: sun8i_ss_cipher drivers/crypto/amlogic/amlogic-gxl-core.c: meson_cipher drivers/crypto/axis/artpec6_crypto.c: artpec6_crypto_common_init drivers/crypto/bcm/cipher.c: spu_skcipher_rx_sg_create drivers/crypto/caam/caamalg.c: aead_edesc_alloc drivers/crypto/caam/caamalg_qi.c: aead_edesc_alloc drivers/crypto/caam/caamalg_qi2.c: aead_edesc_alloc drivers/crypto/caam/caamhash.c: hash_digest_key drivers/crypto/cavium/cpt/cptvf_algs.c: process_request drivers/crypto/cavium/nitrox/nitrox_aead.c: nitrox_process_se_request drivers/crypto/cavium/nitrox/nitrox_skcipher.c: nitrox_process_se_request drivers/crypto/ccp/ccp-crypto-aes-cmac.c: ccp_do_cmac_update drivers/crypto/ccp/ccp-crypto-aes-galois.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-aes-xts.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-aes.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-des3.c: ccp_crypto_enqueue_request drivers/crypto/ccp/ccp-crypto-sha.c: ccp_crypto_enqueue_request drivers/crypto/chelsio/chcr_algo.c: create_cipher_wr drivers/crypto/hisilicon/sec/sec_algs.c: sec_alloc_and_fill_hw_sgl drivers/crypto/hisilicon/sec2/sec_crypto.c: sec_alloc_req_id drivers/crypto/inside-secure/safexcel_cipher.c: safexcel_queue_req drivers/crypto/inside-secure/safexcel_hash.c: safexcel_ahash_enqueue drivers/crypto/ixp4xx_crypto.c: ablk_perform drivers/crypto/marvell/cesa/cipher.c: mv_cesa_skcipher_dma_req_init drivers/crypto/marvell/cesa/hash.c: mv_cesa_ahash_dma_req_init drivers/crypto/marvell/octeontx/otx_cptvf_algs.c: create_ctx_hdr drivers/crypto/n2_core.c: n2_compute_chunks drivers/crypto/picoxcell_crypto.c: spacc_sg_to_ddt drivers/crypto/qat/qat_common/qat_algs.c: qat_alg_skcipher_encrypt drivers/crypto/qce/skcipher.c: qce_skcipher_async_req_handle drivers/crypto/talitos.c : talitos_edesc_alloc drivers/crypto/virtio/virtio_crypto_algs.c: __virtio_crypto_skcipher_do_req drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher Signed-off-by: Mikulas Patocka <[email protected]> [EB: avoid overly-long lines] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-01-09crypto: remove propagation of CRYPTO_TFM_RES_* flagsEric Biggers1-6/+0
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 <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-01-09crypto: remove CRYPTO_TFM_RES_BAD_KEY_LENEric Biggers1-12/+4
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: Eric Biggers <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-12-20crypto: inside-secure - Fix hang case on EIP97 with basic DES/3DES opsPascal van Leeuwen1-1/+2
This patch fixes another hang case on the EIP97 caused by sending invalidation tokens to the hardware when doing basic (3)DES ECB/CBC operations. Invalidation tokens are an EIP197 feature and needed nor supported by the EIP97. So they should not be sent for that device. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-12-20crypto: inside-secure - Fix Unable to fit even 1 command desc error w/ EIP97Pascal van Leeuwen1-2/+9
Due to the additions of support for modes like AES-CCM and AES-GCM, which require large command tokens, the size of the descriptor has grown such that it now does not fit into the descriptor cache of a standard EIP97 anymore. This means that the driver no longer works on the Marvell Armada 3700LP chip (as used on e.g. Espressobin) that it has always supported. Additionally, performance on EIP197's like Marvell A8K may also degrade due to being able to fit less descriptors in the on-chip cache. Putting these tokens into the descriptor was really a hack and not how the design was supposed to be used - resource allocation did not account for it. So what this patch does, is move the command token out of the descriptor. To avoid having to allocate buffers on the fly for these command tokens, they are stuffed in a "shadow ring", which is a circular buffer of fixed size blocks that runs in lock-step with the descriptor ring. i.e. there is one token block per descriptor. The descriptor ring itself is then pre- populated with the pointers to these token blocks so these do not need to be filled in when building the descriptors later. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-11-01crypto: inside-secure - Fixed warnings on inconsistent byte order handlingPascal van Leeuwen1-14/+17
This fixes a bunch of endianness related sparse warnings reported by the kbuild test robot as well as Ben Dooks. Credits for the fix to safexcel.c go to Ben Dooks. Reported-by: kbuild test robot <[email protected]> Reported-by: Ben Dooks <[email protected]> Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-23crypto: inside-secure - Fix build error with CONFIG_CRYPTO_SM3=mPascal van Leeuwen1-6/+2
Always take the zero length hash value for SM3 from the local constant to avoid a reported build error when SM3 is configured to be a module. Fixes: 0f2bc13181ce ("crypto: inside-secure - Added support for...") Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-18crypto: inside-secure - Use PTR_ERR_OR_ZERO in safexcel_xcbcmac_cra_init()YueHaibing1-4/+1
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Signed-off-by: YueHaibing <[email protected]> Acked-by: Antoine Tenart <[email protected]> Acked-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Add HMAC-SHA3 family of authentication algorithmsPascal van Leeuwen1-13/+428
This patch adds support for hmac(sha3-224), hmac(sha3-256), hmac(sha3-384) and hmac(sha3-512) authentication algorithms. The patch has been tested with the eip197c_iewxkbc configuration on the Xilinx VCU118 development board, including the testmgr extra tests. changes since v1: - nothing Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Add SHA3 family of basic hash algorithmsPascal van Leeuwen1-0/+351
This patch adds support for sha3-224, sha3-256, sha3-384 and sha3-512 basic hashes. The patch has been tested with the eip197c_iewxkbc configuration on the Xilinx VCU118 development board, including the testmgr extra tests. changes since v1: - nothing Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Added support for HMAC-SM3 ahashPascal van Leeuwen1-0/+70
Added support for the hmac(sm3) ahash authentication algorithm changes since v1: - added Acked-by tag below, no changes to the source changes since v2: - nothing Acked-by: Antoine Tenart <[email protected]> Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Added support for basic SM3 ahashPascal van Leeuwen1-0/+64
Added support for the SM3 ahash algorithm changes since v1: - moved definition of CONTEXT_CONTROL_CRYPTO_ALG_SM3 (0x7) up above 0xf changes since v2: - allow compilation if CONFIG_CRYPTO_SM3 is not set Acked-by: Antoine Tenart <[email protected]> Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Added support for the AES-CMAC ahashPascal van Leeuwen1-0/+99
This patch adds support for the AES-CMAC authentication algorithm. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Added support for the AES XCBC ahashPascal van Leeuwen1-4/+132
This patch adds support for the AES XCBC authentication algorithm Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Added support for the AES CBCMAC ahashPascal van Leeuwen1-41/+194
This patch adds support for the AES-CBCMAC authentication algorithm. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-10-05crypto: inside-secure - Added support for CRC32Pascal van Leeuwen1-7/+108
This patch adds support for the CRC32 "hash" algorithm Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-09-05crypto: inside-secure - Made .cra_priority value a definePascal van Leeuwen1-12/+12
Instead of having a fixed value (of 300) all over the place, the value for for .cra_priority is now made into a define (SAFEXCEL_CRA_PRIORITY). This makes it easier to play with, e.g. during development. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-09-05crypto: inside-secure - Only enable algorithms advertised by the hardwarePascal van Leeuwen1-0/+12
This patch probes the supported algorithms from the hardware and only registers the ones that the hardware actually supports. This is necessary because this is a generic driver supposed to run on a wide variety of engines, which may or may not implement certain algorithms. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-08-30crypto: inside-secure - Remove redundant algo to engine mapping codePascal van Leeuwen1-12/+0
This removes some code determine which engine has which algorithms which was effectively redundant (may have been forward-looking?) due to always enabling all algorithms for all currently supported engines. A future patch will use a different, more scalable approach to achieve this. This is removed now because otherwise the next patch will add new hardware which would otherwise have to be added to all algorithms, so now is a convenient time to just get rid of this. Signed-off-by: Pascal van Leeuwen <[email protected]> Acked-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-26crypto: inside-secure -reduce hash byte counters to 64 bitsPascal van Leeuwen1-54/+34
This patch recognises the fact that the hardware cannot ever process more than 2,199,023,386,111 bytes of hash or HMAC payload, so there is no point in maintaining 128 bit wide byte counters, 64 bits is more than sufficient Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-26crypto: inside-secure - add support for 0 length HMAC messagesPascal van Leeuwen1-3/+44
This patch adds support for the specific corner case of performing HMAC on an empty string (i.e. payload length is zero). This solves the last failing cryptomgr extratests for HMAC. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-26crypto: inside-secure - add support for arbitrary size hash/HMAC updatesPascal van Leeuwen1-157/+266
This patch fixes an issue with hash and HMAC operations that perform "large" intermediate updates (i.e. combined size > 2 hash blocks) by actually making use of the hardware's hash continue capabilities. The original implementation would cache these updates in a buffer that was 2 hash blocks in size and fail if all update calls combined would overflow that buffer. Which caused the cryptomgr extra tests to fail. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-26crypto: inside-secure - let HW deal with initial hash digestPascal van Leeuwen1-65/+6
The driver was loading the initial digest for hash operations into the hardware explicitly, but this is not needed as the hardware can handle that by itself, which is more efficient and avoids any context record coherence issues. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-26crypto: inside-secure: back out parts of earlier HMAC update workaroundPascal van Leeuwen1-19/+13
This patch backs out some changes done with commit 082ec2d48467 - "add support for HMAC updates" as that update just works around the issue for the basic tests by providing twice the amount of buffering, but this does not solve the case of much larger data blocks such as those performed by the extra tests. This is in preparation of an actual solution in the next patch(es), which does not actually require any extra buffering at all. Signed-off-by: Pascal van Leeuwen <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - fix use of the SG listAntoine Tenart1-2/+1
Replace sg_nents_for_len by sg_nents when DMA mapping/unmapping buffers and when looping over the SG entries. This fix cases where the SG entries aren't used fully, which would in such cases led to using fewer SG entries than needed (and thus the engine wouldn't have access to the full input data and the result would be wrong). Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - add support for HMAC updatesAntoine Tenart1-21/+37
This patch adds support for HMAC updates in the Inside Secure SafeXcel crypto engine driver. Updates were supported for hash algorithms, but were never enabled for HMAC ones. This fixes boot time test issues. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - fix queued len computationAntoine Tenart1-3/+5
This patch fixes the queued len computation, which could theoretically be wrong if req->len[1] - req->processed[1] > 1. Be future-proof here, and fix it. Fixes: b460edb6230a ("crypto: inside-secure - sha512 support") Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - fix zeroing of the request in ahash_exit_invAntoine Tenart1-1/+1
A request is zeroed in safexcel_ahash_exit_inv(). This request total size is EIP197_AHASH_REQ_SIZE while the memset zeroing it uses sizeof(struct ahash_request), which happens to be less than EIP197_AHASH_REQ_SIZE. This patch fixes it. Fixes: f6beaea30487 ("crypto: inside-secure - authenc(hmac(sha256), cbc(aes)) support") Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - unify cache resetAntoine Tenart1-0/+2
This patch unify the way the cache related data is zeroed when the cache buffer is DMA unmapped. It should not change the driver behaviour, but improves the code safety and readability. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - remove useless checkAntoine Tenart1-13/+11
When sending an ahash request, the code checks for the extra variable not to be 0. This check is useless as the extra variable can't be 0 at this point (it is checked on the line just before). This patch does not modify the driver behaviour in any way. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-06crypto: inside-secure - move commentAntoine Tenart1-3/+4
This cosmetic patch moves a comment before the condition it is related to. The patch does not change the driver behaviour in any way. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-20crypto: inside-secure - switch to SPDX identifiersAntoine Tenart1-4/+1
Use the appropriate SPDX license identifiers and drop the license text. This patch is only cosmetic. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: remove redundant type flags from tfm allocationEric Biggers1-2/+1
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 <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - remove request list to improve performanceOfer Heifetz1-23/+8
This patch main goal is to improve driver performance by moving the crypto request from a list to a RDR ring shadow. This is possible since there is one producer and one consume for this RDR request shadow and one ring descriptor is left unused. Doing this change eliminates the use of spinlock when accessing the descriptor ring and the need to dynamicaly allocate memory per crypto request. The crypto request is placed in the first RDR shadow descriptor only if there are enough descriptors, when the result handler is invoked, it fetches the first result descriptor from RDR shadow. Signed-off-by: Ofer Heifetz <[email protected]> Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - hmac(md5) supportOfer Heifetz1-0/+57
This patch adds support for the hmac(md5) algorithm in the Inside Secure SafeXcel cryptographic engine driver. Signed-off-by: Ofer Heifetz <[email protected]> Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - md5 supportOfer Heifetz1-2/+67
This patch adds the MD5 algorithm support to the Inside Secure SafeXcel cryptographic engine driver. Signed-off-by: Ofer Heifetz <[email protected]> Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - eip197d supportAntoine Tenart1-10/+10
This patch adds support for the eip197d engine to the Inside Secure SafeXcel cryptographic driver. This new engine is similar to the eip197b and reuse most of its code. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - add an invalidation flagAntoine Tenart1-4/+4
Add a flags field in the private structure, and a first flag for engines needing context invalidation (currently only the eip197b). The invalidation is needed when the engine includes a TRC cache, which will also be true for the upcoming addition of the eip197d engine. Suggested-by: Ofer Heifetz <[email protected]> Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - filter out the algorithms by engineAntoine Tenart1-0/+10
EIP engines do not support the same set of algorithms. So far the supported engines in the Inside Secure SafeXcel driver support the same set of algorithms, but that won't be true for all engines. This patch adds an 'engines' field in the algorithm definitions so that they only are registered when using a compatible cryptographic engine. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-07-09crypto: inside-secure - use precise compatiblesAntoine Tenart1-4/+4
At first we used two compatibles in the SafeXcel driver, named after the engine revision: eip97 and eip197. However this family of engines has more precise versions and in fact we're supporting the eip97ies and eip197b. More versions will be supported in the future, such as the eip197d, and we'll need to differentiate them. This patch fixes the compatibles used in the driver, to now use precise ones. The two historical compatibles are kept for backward compatibility. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-06-22crypto: inside-secure - hmac(sha384) supportAntoine Tenart1-0/+56
This patch adds the hmac(sha384) algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-06-22crypto: inside-secure - sha384 supportAntoine Tenart1-1/+75
This patch adds the sha384 algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-06-22crypto: inside-secure - hmac(sha512) supportAntoine Tenart1-2/+58
This patch adds the hmac(sha512) algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-06-22crypto: inside-secure - sha512 supportAntoine Tenart1-33/+145
This patch adds the sha512 algorithm support to the Inside Secure SafeXcel driver. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-06-22crypto: inside-secure - improve the counter computationAntoine Tenart1-7/+5
A counter is given to the engine when finishing hash computation. It currently uses the blocksize while it counts the number of 64 bytes blocks given to the engine. This works well for all algorithms so far, as SHA1, SHA224 and SHA256 all have a blocksize of 64 bytes, but others algorithms such as SHA512 wouldn't work. Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2018-06-22crypto: inside-secure - use the error handler for invalidation requestsAntoine Tenart1-5/+2
This patch reworks the way invalidation request handlers handle the result descriptor errors, to use the common error handling function. This improves the drivers in terms of readability and maintainability. Suggested-by: Ofer Heifetz <[email protected]> Signed-off-by: Antoine Tenart <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.