aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-08-22crypto: ccp - Ignore unconfigured CCP device on suspend/resumeGary R Hook1-0/+8
If a CCP is unconfigured (e.g. there are no available queues) then there will be no data structures allocated for the device. Thus, we must check for validity of a pointer before trying to access structure members. Fixes: 720419f01832f ("crypto: ccp - Introduce the AMD Secure Processor device") Cc: <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-08-02crypto: ccp - Ignore tag length when decrypting GCM ciphertextGary R Hook1-2/+1
AES GCM input buffers for decryption contain AAD+CTEXT+TAG. Only decrypt the ciphertext, and use the tag for comparison. Fixes: 36cf515b9bbe2 ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-08-02crypto: ccp - Add support for valid authsize values less than 16Gary R Hook3-5/+37
AES GCM encryption allows for authsize values of 4, 8, and 12-16 bytes. Validate the requested authsize, and retain it to save in the request context. Fixes: 36cf515b9bbe2 ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-08-02crypto: ccp - Fix oops by properly managing allocated structuresGary R Hook1-2/+2
A plaintext or ciphertext length of 0 is allowed in AES, in which case no encryption occurs. Ensure that we don't clean up data structures that were never allocated. Fixes: 36cf515b9bbe2 ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-18padata: use smp_mb in padata_reorder to avoid orphaned padata jobsDaniel Jordan1-0/+12
Testing padata with the tcrypt module on a 5.2 kernel... # modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3 # modprobe tcrypt mode=211 sec=1 ...produces this splat: INFO: task modprobe:10075 blocked for more than 120 seconds. Not tainted 5.2.0-base+ #16 modprobe D 0 10075 10064 0x80004080 Call Trace: ? __schedule+0x4dd/0x610 ? ring_buffer_unlock_commit+0x23/0x100 schedule+0x6c/0x90 schedule_timeout+0x3b/0x320 ? trace_buffer_unlock_commit_regs+0x4f/0x1f0 wait_for_common+0x160/0x1a0 ? wake_up_q+0x80/0x80 { crypto_wait_req } # entries in braces added by hand { do_one_aead_op } { test_aead_jiffies } test_aead_speed.constprop.17+0x681/0xf30 [tcrypt] do_test+0x4053/0x6a2b [tcrypt] ? 0xffffffffa00f4000 tcrypt_mod_init+0x50/0x1000 [tcrypt] ... The second modprobe command never finishes because in padata_reorder, CPU0's load of reorder_objects is executed before the unlocking store in spin_unlock_bh(pd->lock), causing CPU0 to miss CPU1's increment: CPU0 CPU1 padata_reorder padata_do_serial LOAD reorder_objects // 0 INC reorder_objects // 1 padata_reorder TRYLOCK pd->lock // failed UNLOCK pd->lock CPU0 deletes the timer before returning from padata_reorder and since no other job is submitted to padata, modprobe waits indefinitely. Add a pair of full barriers to guarantee proper ordering: CPU0 CPU1 padata_reorder padata_do_serial UNLOCK pd->lock smp_mb() LOAD reorder_objects INC reorder_objects smp_mb__after_atomic() padata_reorder TRYLOCK pd->lock smp_mb__after_atomic is needed so the read part of the trylock operation comes after the INC, as Andrea points out. Thanks also to Andrea for help with writing a litmus test. Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface") Signed-off-by: Daniel Jordan <[email protected]> Cc: <[email protected]> Cc: Andrea Parri <[email protected]> Cc: Boqun Feng <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Steffen Klassert <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
2019-07-18crypto: ccp - Fix SEV_VERSION_GREATER_OR_EQUALDavid Rientjes1-7/+12
SEV_VERSION_GREATER_OR_EQUAL() will fail if upgrading from 2.2 to 3.1, for example, because the minor version is not equal to or greater than the major. Fix this and move to a static inline function for appropriate type checking. Fixes: edd303ff0e9e ("crypto: ccp - Add DOWNLOAD_FIRMWARE SEV command") Reported-by: Cfir Cohen <[email protected]> Signed-off-by: David Rientjes <[email protected]> Acked-by: Tom Lendacky <[email protected]> Acked-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-18crypto: ccp/gcm - use const time tag comparison.Cfir Cohen1-1/+2
Avoid leaking GCM tag through timing side channel. Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: <[email protected]> # v4.12+ Signed-off-by: Cfir Cohen <[email protected]> Acked-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-12crypto: ccp - memset structure fields to zero before reuseHook, Gary1-1/+11
The AES GCM function reuses an 'op' data structure, which members contain values that must be cleared for each (re)use. This fix resolves a crypto self-test failure: alg: aead: gcm-aes-ccp encryption test failed (wrong result) on test vector 2, cfg="two even aligned splits" Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs") Cc: <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-12crypto: crypto4xx - fix a potential double free in ppc4xx_trng_probeWen Yang1-1/+0
There is a possible double free issue in ppc4xx_trng_probe(): 85: dev->trng_base = of_iomap(trng, 0); 86: of_node_put(trng); ---> released here 87: if (!dev->trng_base) 88: goto err_out; ... 110: ierr_out: 111: of_node_put(trng); ---> double released here ... This issue was detected by using the Coccinelle software. We fix it by removing the unnecessary of_node_put(). Fixes: 5343e674f32f ("crypto4xx: integrate ppc4xx-rng into crypto4xx") Signed-off-by: Wen Yang <[email protected]> Cc: <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Allison Randal <[email protected]> Cc: Armijn Hemel <[email protected]> Cc: Julia Lawall <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Julia Lawall <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-12crypto: stm32/hash - Fix incorrect printk modifier for size_tHerbert Xu1-1/+1
This patch fixes a warning when compiling stm32 because %d is being used on a size_t argument instead of %zd. Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: stm32/hash - remove interruptible condition for dmaLionel Debieve1-2/+2
When DMA is used, waiting for completion must not be interruptible as it can generate an error that is not handle by the driver. There is no need to put the completion interruptible in this driver. Signed-off-by: Lionel Debieve <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: stm32/hash - Fix hmac issue more than 256 bytesLionel Debieve1-1/+1
Correct condition for the second hmac loop. Key must be only set in the first loop. Initial condition was wrong, HMAC_KEY flag was not properly checked. Signed-off-by: Lionel Debieve <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: stm32/crc32 - rename driver fileLionel Debieve2-1/+1
Use the same naming convention for all stm32 crypto drivers. Signed-off-by: Lionel Debieve <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: amcc - remove memset after dma_alloc_coherentFuqian Huang1-1/+0
In commit af7ddd8a627c ("Merge tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping"), dma_alloc_coherent has already zeroed the memory. So memset is not needed. Signed-off-by: Fuqian Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: ccp - Switch to SPDX license identifiersHook, Gary22-88/+20
Add an SPDX identifier and remove any specific statements. Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: ccp - Validate the the error value used to index error messagesHook, Gary2-46/+52
The error code read from the queue status register is only 6 bits wide, but we need to verify its value is within range before indexing the error messages. Fixes: 81422badb3907 ("crypto: ccp - Make syslog errors human-readable") Cc: <[email protected]> Reported-by: Cfir Cohen <[email protected]> Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: doc - Fix formatting of new crypto engine contentHook, Gary1-38/+73
Tidy up the formatting/grammar in crypto_engine.rst. Use bulleted lists where appropriate. Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: doc - Add parameter documentationHook, Gary2-1/+12
Fill in missing parameter descriptions for the compression algorithm, then pick them up to document for the compression_alg structure. Signed-off-by: Gary R Hook <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTRArd Biesheuvel3-31/+75
This implements 5-way interleaving for ECB, CBC decryption and CTR, resulting in a speedup of ~11% on Marvell ThunderX2, which has a very deep pipeline and therefore a high issue latency for NEON instructions operating on the same registers. Note that XTS is left alone: implementing 5-way interleave there would either involve spilling of the calculated tweaks to the stack, or recalculating them after the encryption operation, and doing either of those would most likely penalize low end cores. For ECB, this is not a concern at all, given that we have plenty of spare registers. For CTR and CBC decryption, we take advantage of the fact that v16 is not used by the CE version of the code (which is the only one targeted by the optimization), and so we can reshuffle the code a bit and avoid having to spill to memory (with the exception of one extra reload in the CBC routine) Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: arm64/aes-ce - add 5 way interleave routinesArd Biesheuvel3-68/+52
In preparation of tweaking the accelerated AES chaining mode routines to be able to use a 5-way stride, implement the core routines to support processing 5 blocks of input at a time. While at it, drop the 2 way versions, which have been unused for a while now. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: talitos - drop icv_oolChristophe Leroy2-5/+0
icv_ool is not used anymore, drop it. Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: talitos - fix hash on SEC1.Christophe Leroy1-28/+41
On SEC1, hash provides wrong result when performing hashing in several steps with input data SG list has more than one element. This was detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS: [ 44.185947] alg: hash: md5-talitos test failed (wrong result) on test vector 6, cfg="random: may_sleep use_finup src_divs=[<reimport>25.88%@+8063, <flush>24.19%@+9588, 28.63%@+16333, <reimport>4.60%@+6756, 16.70%@+16281] dst_divs=[71.61%@alignmask+16361, 14.36%@+7756, 14.3%@+" [ 44.325122] alg: hash: sha1-talitos test failed (wrong result) on test vector 3, cfg="random: inplace use_final src_divs=[<flush,nosimd>16.56%@+16378, <reimport>52.0%@+16329, 21.42%@alignmask+16380, 10.2%@alignmask+16380] iv_offset=39" [ 44.493500] alg: hash: sha224-talitos test failed (wrong result) on test vector 4, cfg="random: use_final nosimd src_divs=[<reimport>52.27%@+7401, <reimport>17.34%@+16285, <flush>17.71%@+26, 12.68%@+10644] iv_offset=43" [ 44.673262] alg: hash: sha256-talitos test failed (wrong result) on test vector 4, cfg="random: may_sleep use_finup src_divs=[<reimport>60.6%@+12790, 17.86%@+1329, <reimport>12.64%@alignmask+16300, 8.29%@+15, 0.40%@+13506, <reimport>0.51%@+16322, <reimport>0.24%@+16339] dst_divs" This is due to two issues: - We have an overlap between the buffer used for copying the input data (SEC1 doesn't do scatter/gather) and the chained descriptor. - Data copy is wrong when the previous hash left less than one blocksize of data to hash, implying a complement of the previous block with a few bytes from the new request. Fix it by: - Moving the second descriptor after the buffer, as moving the buffer after the descriptor would make it more complex for other cipher operations (AEAD, ABLKCIPHER) - Skip the bytes taken from the new request to complete the previous one by moving the SG list forward. Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") Cc: [email protected] Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-07-03crypto: talitos - move struct talitos_edesc into talitos.hChristophe Leroy2-30/+30
Moves struct talitos_edesc into talitos.h so that it can be used from any place in talitos.c It will be required for next patch ("crypto: talitos - fix hash on SEC1") Signed-off-by: Christophe Leroy <[email protected]> Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
2019-07-03lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZEChristophe Leroy1-4/+5
All mapping iterator logic is based on the assumption that sg->offset is always lower than PAGE_SIZE. But there are situations where sg->offset is such that the SG item is on the second page. In that case sg_copy_to_buffer() fails properly copying the data into the buffer. One of the reason is that the data will be outside the kmapped area used to access that data. This patch fixes the issue by adjusting the mapping iterator offset and pgoffset fields such that offset is always lower than PAGE_SIZE. Signed-off-by: Christophe Leroy <[email protected]> Fixes: 4225fc8555a9 ("lib/scatterlist: use page iterator in the mapping iterator") Cc: [email protected] Signed-off-by: Herbert Xu <[email protected]>
2019-06-28crypto/NX: Set receive window credits to max number of CRBs in RxFIFOHaren Myneni1-3/+5
System gets checkstop if RxFIFO overruns with more requests than the maximum possible number of CRBs in FIFO at the same time. The max number of requests per window is controlled by window credits. So find max CRBs from FIFO size and set it to receive window credits. Fixes: b0d6c9bab5e4 ("crypto/nx: Add P9 NX support for 842 compression engine") CC: [email protected] # v4.14+ Signed-off-by:Haren Myneni <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: asymmetric_keys - select CRYPTO_HASH where neededArnd Bergmann1-0/+3
Build testing with some core crypto options disabled revealed a few modules that are missing CRYPTO_HASH: crypto/asymmetric_keys/x509_public_key.o: In function `x509_get_sig_params': x509_public_key.c:(.text+0x4c7): undefined reference to `crypto_alloc_shash' x509_public_key.c:(.text+0x5e5): undefined reference to `crypto_shash_digest' crypto/asymmetric_keys/pkcs7_verify.o: In function `pkcs7_digest.isra.0': pkcs7_verify.c:(.text+0xab): undefined reference to `crypto_alloc_shash' pkcs7_verify.c:(.text+0x1b2): undefined reference to `crypto_shash_digest' pkcs7_verify.c:(.text+0x3c1): undefined reference to `crypto_shash_update' pkcs7_verify.c:(.text+0x411): undefined reference to `crypto_shash_finup' This normally doesn't show up in randconfig tests because there is a large number of other options that select CRYPTO_HASH. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: serpent - mark __serpent_setkey_sbox noinlineArnd Bergmann1-1/+7
The same bug that gcc hit in the past is apparently now showing up with clang, which decides to inline __serpent_setkey_sbox: crypto/serpent_generic.c:268:5: error: stack frame size of 2112 bytes in function '__serpent_setkey' [-Werror,-Wframe-larger-than=] Marking it 'noinline' reduces the stack usage from 2112 bytes to 192 and 96 bytes, respectively, and seems to generate more useful object code. Fixes: c871c10e4ea7 ("crypto: serpent - improve __serpent_setkey with UBSAN") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: testmgr - dynamically allocate crypto_shashArnd Bergmann1-6/+13
The largest stack object in this file is now the shash descriptor. Since there are many other stack variables, this can push it over the 1024 byte warning limit, in particular with clang and KASAN: crypto/testmgr.c:1693:12: error: stack frame size of 1312 bytes in function '__alg_test_hash' [-Werror,-Wframe-larger-than=] Make test_hash_vs_generic_impl() do the same thing as the corresponding eaed and skcipher functions by allocating the descriptor dynamically. We can still do better than this, but it brings us well below the 1024 byte limit. Suggested-by: Eric Biggers <[email protected]> Fixes: 9a8a6b3f0950 ("crypto: testmgr - fuzz hashes against their generic implementation") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: testmgr - dynamically allocate testvec_configArnd Bergmann1-11/+32
On arm32, we get warnings about high stack usage in some of the functions: crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function 'alg_test_aead' [-Werror,-Wframe-larger-than=] static int alg_test_aead(const struct alg_test_desc *desc, const char *driver, ^ crypto/testmgr.c:1693:12: error: stack frame size of 1312 bytes in function '__alg_test_hash' [-Werror,-Wframe-larger-than=] static int __alg_test_hash(const struct hash_testvec *vecs, ^ On of the larger objects on the stack here is struct testvec_config, so change that to dynamic allocation. Fixes: 40153b10d91c ("crypto: testmgr - fuzz AEADs against their generic implementation") Fixes: d435e10e67be ("crypto: testmgr - fuzz skciphers against their generic implementation") Fixes: 9a8a6b3f0950 ("crypto: testmgr - fuzz hashes against their generic implementation") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: talitos - eliminate unneeded 'done' functions at build timeChristophe Leroy1-1/+1
When building for SEC1 only, talitos2_done functions are unneeded and should go away. For this, use has_ftr_sec1() which will always return true when only SEC1 support is being built, allowing GCC to drop TALITOS2 functions. Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: sun4i-ss - reduce stack usageArnd Bergmann1-17/+30
After the latest addition, the stack usage of sun4i_ss_cipher_poll grew beyond the warning limit when KASAN is enabled: drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:118:12: error: stack frame size of 1152 bytes in function 'sun4i_ss_cipher_poll' [-Werror,-Wframe-larger-than=] static int sun4i_ss_cipher_poll(struct skcipher_request *areq) Reduce it in three ways: - split out the new code into a separate function so its stack usage can overlap that of the sun4i_ss_opti_poll() code path - mark both special cases as noinline_for_stack, which should ideally result in a tail call that frees the rest of the stack - move the buf and obuf variables into the code blocks in which they are used. The three separate functions now use 144, 640 and 304 bytes of kernel stack, respectively. Fixes: 0ae1f46c55f8 ("crypto: sun4i-ss - fallback when length is not multiple of blocksize") Signed-off-by: Arnd Bergmann <[email protected]> Tested-by: Corentin LABBE <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: ccree - add HW engine config checkGilad Ben-Yossef3-0/+38
Add check to verify the stated device tree HW configuration matches the HW. Signed-off-by: Gilad Ben-Yossef <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: ccree - prevent isr handling in case driver is suspendedOfir Drang3-0/+16
ccree irq may be shared with other devices, in order to prevent ccree isr handling while device maybe suspended we added a check to verify that the device is not suspended. Signed-off-by: Ofir Drang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: ccree - check that cryptocell reset completedOfir Drang4-1/+43
In case of driver probe and pm resume we need to check that the cryptocell hardware reset cycle is completed. during the reset cycle that Cryptocell provide read only access to the APB interface which allows to verify through the CC registers that the reset is completed. Until reset completion we assume that any write/crypto operation is blocked. Signed-off-by: Ofir Drang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-27crypto: ccree - Relocate driver irq registration after clk init[email protected]1-9/+9
Signed-off-by: Ofir Drang <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: nx - no need to check return value of debugfs_create functionsGreg Kroah-Hartman3-61/+26
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Also, there is no need to store the individual debugfs file names, especially as the whole directiry is deleted at once, so remove the unneeded structure entirely. Cc: "Breno Leitão" <[email protected]> Cc: Nayna Jain <[email protected]> Cc: Paulo Flabiano Smorigo <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Herbert Xu <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20fs: cifs: switch to RC4 library interfaceArd Biesheuvel3-48/+17
The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher, of which only a single generic C code implementation exists. This means that going through all the trouble of using scatterlists etc buys us very little, and we're better off just invoking the arc4 library directly. This also reverts commit 5f4b55699aaf ("CIFS: Fix BUG() in calc_seckey()"), since it is no longer necessary to allocate sec_key on the heap. Cc: [email protected] Cc: Steve French <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Steve French <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20ppp: mppe: switch to RC4 library interfaceArd Biesheuvel2-85/+15
The MPPE code uses the sync skcipher to invoke the ecb(arc4) skcipher, of which only a single generic C code implementation exists. This means that going through all the trouble of using scatterlists etc buys us very little, and we're better off just invoking the arc4 library directly. Note that the SHA1 shash used by this driver has several accelerated implementations for various architectures, so retaining that part does make sense. Cc: [email protected] Cc: Paul Mackerras <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: arc4 - remove cipher implementationArd Biesheuvel2-50/+16
There are no remaining users of the cipher implementation, and there are no meaningful ways in which the arc4 cipher can be combined with templates other than ECB (and the way we do provide that combination is highly dubious to begin with). So let's drop the arc4 cipher altogether, and only keep the ecb(arc4) skcipher, which is used in various places in the kernel. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20net/lib80211: move TKIP handling to ARC4 library codeArd Biesheuvel2-31/+18
The crypto API abstraction is not very useful for invoking ciphers directly, especially in the case of arc4, which only has a generic implementation in C. So let's invoke the library code directly. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20net/lib80211: move WEP handling to ARC4 library codeArd Biesheuvel2-38/+14
The crypto API abstraction is not very useful for invoking ciphers directly, especially in the case of arc4, which only has a generic implementation in C. So let's invoke the library code directly. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20net/mac80211: move WEP handling to ARC4 library interfaceArd Biesheuvel11-60/+30
The WEP code in the mac80211 subsystem currently uses the crypto API to access the arc4 (RC4) cipher, which is overly complicated, and doesn't really have an upside in this particular case, since ciphers are always synchronous and therefore always implemented in software. Given that we have no accelerated software implementations either, it is much more straightforward to invoke a generic library interface directly. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: arc4 - refactor arc4 core code into separate libraryArd Biesheuvel7-60/+95
Refactor the core rc4 handling so we can move most users to a library interface, permitting us to drop the cipher interface entirely in a future patch. This is part of an effort to simplify the crypto API and improve its robustness against incorrect use. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: talitos - fix max key size for sha384 and sha512Christophe Leroy1-1/+1
Below commit came with a typo in the CONFIG_ symbol, leading to a permanently reduced max key size regarless of the driver capabilities. Reported-by: Horia Geantă <[email protected]> Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1") Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: vmx - Document CTR mode counter width quirksDaniel Axtens1-2/+20
The CTR code comes from OpenSSL, where it does a 32-bit counter. The kernel has a 128-bit counter. This difference has lead to issues. Document it. Signed-off-by: Daniel Axtens <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: caam - update IV using HW supportHoria Geantă5-146/+163
Modify drivers to perform skcipher IV update using the crypto engine, instead of performing the operation in SW. Besides being more efficient, this also fixes IV update for CTR mode. Output HW S/G table is appended with an entry pointing to the same IV buffer used as input (which is now mapped BIDIRECTIONAL). AS (Algorithm State) parameter of the OPERATION command is changed from INIFINAL to INIT in descriptors used by ctr(aes), cbc(aes). This is needed since in case FINAL bit is set, HW skips IV updating in the Context Register for the last data block. Signed-off-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20crypto: caam - use len instead of nents for bulding HW S/G tableHoria Geantă8-99/+105
Currently, conversion of SW S/G table into HW S/G layout relies on nents returned by sg_nents_for_len(sg, len). However this leaves the possibility of HW S/G referencing more data then needed: since buffer length in HW S/G entries is filled using sg_dma_len(sg), the last entry in HW S/G table might have a length that is bigger than needed for the crypto request. This way of S/G table conversion is fine, unless after converting a table more entries have to be appended to the HW S/G table. In this case, crypto engine would access data from the S/G entry having the incorrect length, instead of advancing in the S/G table. This situation doesn't exist, but the upcoming implementation of IV update for skcipher algorithms needs to add a S/G entry after req->dst S/G (corresponding to output IV). Signed-off-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20hwrng: iproc-rng200 - Add support for 7211Florian Fainelli1-0/+1
BCM7211 features a RNG200 hardware random number generator block, add support for this chip by matching the chip-specific compatible string. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20dt-bindings: rng: Document BCM7211 RNG compatible stringFlorian Fainelli1-0/+1
BCM7211 features a RNG200 block, document its compatible string. Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2019-06-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Herbert Xu6-129/+100
Merge crypto tree to pick up vmx changes.
Powered by cgit, Gruvboxed by Blaster4385.