- 16 3月, 2018 9 次提交
-
-
由 Harsh Jain 提交于
Send multiple WRs to H/W when No. of entries received in scatter list cannot be sent in single request. Signed-off-by: NHarsh Jain <harsh@chelsio.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Harsh Jain 提交于
We use ctr(aes) to fallback rfc3686(ctr) request. Send updated IV to fallback path. Signed-off-by: NHarsh Jain <harsh@chelsio.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Harsh Jain 提交于
CBC Decryption requires Last Block as IV. In case src/dst buffer are same last block will be replaced by plain text. This patch copies the Last Block before sending request to HW. Signed-off-by: NHarsh Jain <harsh@chelsio.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Harsh Jain 提交于
ulptx header cannot have length > 64k. Adjust length accordingly. Signed-off-by: NHarsh Jain <harsh@chelsio.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Harsh Jain 提交于
Replace DIV_ROUND_UP to roundup or rounddown Signed-off-by: NHarsh Jain <harsh@chelsio.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Vladimir Zapolskiy 提交于
The driver works well on i.MX31 powered boards with device description taken from board device tree, the only change to add to the driver is the missing OF device id, the affected list of included headers and indentation in platform driver struct are beautified a little. Signed-off-by: NVladimir Zapolskiy <vz@mleia.com> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com> Reviewed-by: NKim Phillips <kim.phillips@arm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Vladimir Zapolskiy 提交于
Freescale i.MX21 and i.MX31 SoCs contain a Random Number Generator Accelerator module (RNGA), which is replaced by RNGB and RNGC modules on later i.MX SoC series, the change adds a new compatible property to describe the controller. Since all versions of Freescale RNG modules are legacy, apparently the documentation file has no more potential for further extensions, nevertheless generalize it by removing explicit RNGC specifics. Signed-off-by: NVladimir Zapolskiy <vz@mleia.com> Reviewed-by: NRob Herring <robh@kernel.org> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Eric Biggers 提交于
Add a NEON-accelerated implementation of Speck128-XTS and Speck64-XTS for ARM64. This is ported from the 32-bit version. It may be useful on devices with 64-bit ARM CPUs that don't have the Cryptography Extensions, so cannot do AES efficiently -- e.g. the Cortex-A53 processor on the Raspberry Pi 3. It generally works the same way as the 32-bit version, but there are some slight differences due to the different instructions, registers, and syntax available in ARM64 vs. in ARM32. For example, in the 64-bit version there are enough registers to hold the XTS tweaks for each 128-byte chunk, so they don't need to be saved on the stack. Benchmarks on a Raspberry Pi 3 running a 64-bit kernel: Algorithm Encryption Decryption --------- ---------- ---------- Speck64/128-XTS (NEON) 92.2 MB/s 92.2 MB/s Speck128/256-XTS (NEON) 75.0 MB/s 75.0 MB/s Speck128/256-XTS (generic) 47.4 MB/s 35.6 MB/s AES-128-XTS (NEON bit-sliced) 33.4 MB/s 29.6 MB/s AES-256-XTS (NEON bit-sliced) 24.6 MB/s 21.7 MB/s The code performs well on higher-end ARM64 processors as well, though such processors tend to have the Crypto Extensions which make AES preferred. For example, here are the same benchmarks run on a HiKey960 (with CPU affinity set for the A73 cores), with the Crypto Extensions implementation of AES-256-XTS added: Algorithm Encryption Decryption --------- ----------- ----------- AES-256-XTS (Crypto Extensions) 1273.3 MB/s 1274.7 MB/s Speck64/128-XTS (NEON) 359.8 MB/s 348.0 MB/s Speck128/256-XTS (NEON) 292.5 MB/s 286.1 MB/s Speck128/256-XTS (generic) 186.3 MB/s 181.8 MB/s AES-128-XTS (NEON bit-sliced) 142.0 MB/s 124.3 MB/s AES-256-XTS (NEON bit-sliced) 104.7 MB/s 91.1 MB/s Signed-off-by: NEric Biggers <ebiggers@google.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Markus Elfring 提交于
Reuse existing functionality from memdup_user() instead of keeping duplicate source code. This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> Reviewed-by: NBrijesh Singh <brijesh.singh@amd.com> Acked-by: NGary R Hook <gary.hook@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 09 3月, 2018 23 次提交
-
-
由 Gary R Hook 提交于
Any change to the result buffer should only happen on final, finup and digest operations. Changes to the buffer for update, import, export, etc, are not allowed. Fixes: 66d7b9f6175e ("crypto: testmgr - test misuse of result in ahash") Signed-off-by: NGary R Hook <gary.hook@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Wu Fengguang 提交于
Fixes: 09c0f03b ("crypto: x86/des3_ede - convert to skcipher interface") Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Acked-by: NEric Biggers <ebiggers@google.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 James Bottomley 提交于
Apparently the ecdh use case was in bluetooth which always has single element scatterlists, so the ecdh module was hard coded to expect them. Now we're using this in TPM, we need multi-element scatterlists, so remove this limitation. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 James Bottomley 提交于
TPM security routines require encryption and decryption with AES in CFB mode, so add it to the Linux Crypto schemes. CFB is basically a one time pad where the pad is generated initially from the encrypted IV and then subsequently from the encrypted previous block of ciphertext. The pad is XOR'd into the plain text to get the final ciphertext. https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#CFBSigned-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Krzysztof Kozlowski 提交于
Improve the code (safety and readability) by indicating that data passed through pointer is not modified. This adds const keyword in many places, most notably: - the driver data (pointer to struct samsung_aes_variant), - scatterlist addresses written as value to device registers, - key and IV arrays. Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Krzysztof Kozlowski 提交于
ahash_request 'req' argument passed by the caller s5p_hash_handle_queue() cannot be NULL here because it is obtained from non-NULL pointer via container_of(). This fixes smatch warning: drivers/crypto/s5p-sss.c:1213 s5p_hash_prepare_request() warn: variable dereferenced before check 'req' (see line 1208) Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Krzysztof Kozlowski 提交于
Commit 8043bb1a ("crypto: omap-sham - convert driver logic to use sgs for data xmit") removed the if() clause leaving the statement as is. The intention was in that case to finish the request always so the goto instruction seems sensible. Remove the indentation to fix Smatch warning: drivers/crypto/omap-sham.c:1761 omap_sham_done_task() warn: inconsistent indenting Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Acked-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Krzysztof Kozlowski 提交于
ahash_request 'req' argument passed by the caller omap_sham_handle_queue() cannot be NULL here because it is obtained from non-NULL pointer via container_of(). This fixes smatch warning: drivers/crypto/omap-sham.c:812 omap_sham_prepare_request() warn: variable dereferenced before check 'req' (see line 805) Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org> Acked-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Atul Gupta 提交于
The Inline IPSec driver does not offload csum. Signed-off-by: NAtul Gupta <atul.gupta@chelsio.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Gregory CLEMENT 提交于
On Armada 7K/8K we need to explicitly enable the register clock. This clock is optional because not all the SoCs using this IP need it but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updating accordingly. Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Gregory CLEMENT 提交于
clk_disable_unprepare() already checks that the clock pointer is valid. No need to test it before calling it. Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tero Kristo 提交于
Crypto driver queue size can now be configured from userspace. This allows optimizing the queue usage based on use case. Default queue size is still 10 entries. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tero Kristo 提交于
Crypto driver fallback size can now be configured from userspace. This allows optimizing the DMA usage based on use case. Detault fallback size of 200 is still used. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tero Kristo 提交于
Crypto driver queue size can now be configured from userspace. This allows optimizing the queue usage based on use case. Default queue size is still 10 entries. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tero Kristo 提交于
Crypto driver fallback size can now be configured from userspace. This allows optimizing the DMA usage based on use case. Default fallback size of 256 is still used. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tero Kristo 提交于
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled has a constraint that DMA can be done with the initial 2GB and marks it as ZONE_DMA. But openssl when used with cryptodev does not make sure that input buffer is DMA capable. So, adding a check to verify if the input buffer is capable of DMA. Signed-off-by: NTero Kristo <t-kristo@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Tero Kristo 提交于
In certain platforms like DRA7xx having memory > 2GB with LPAE enabled has a constraint that DMA can be done with the initial 2GB and marks it as ZONE_DMA. But openssl when used with cryptodev does not make sure that input buffer is DMA capable. So, adding a check to verify if the input buffer is capable of DMA. Signed-off-by: NTero Kristo <t-kristo@ti.com> Reported-by: NAparna Balasubramanian <aparnab@ti.com> Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 LEROY Christophe 提交于
req_ctx->hw_context is mainly used only by the HW. So it is not needed to sync the HW and the CPU each time hw_context in DMA mapped. This patch modifies the DMA mapping in order to limit synchronisation to necessary situations. Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 LEROY Christophe 提交于
Commit 49f9783b ("crypto: talitos - do hw_context DMA mapping outside the requests") introduced a persistent dma mapping of req_ctx->hw_context Commit 37b5e889 ("crypto: talitos - chain in buffered data for ahash on SEC1") introduced a persistent dma mapping of req_ctx->buf As there is no destructor for req_ctx (the request context), the associated dma handlers where set in ctx (the tfm context). This is wrong as several hash operations can run with the same ctx. This patch removes this persistent mapping. Reported-by: NHoria Geanta <horia.geanta@nxp.com> Cc: <stable@vger.kernel.org> Fixes: 49f9783b ("crypto: talitos - do hw_context DMA mapping outside the requests") Fixes: 37b5e889 ("crypto: talitos - chain in buffered data for ahash on SEC1") Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr> Tested-by: NHoria Geantă <horia.geanta@nxp.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Colin Ian King 提交于
Functions cavium_rng_remove and cavium_rng_remove_vf are local to the source and do not need to be in global scope, so make them static. Cleans up sparse warnings: drivers/char/hw_random/cavium-rng-vf.c:80:7: warning: symbol 'cavium_rng_remove_vf' was not declared. Should it be static? drivers/char/hw_random/cavium-rng.c:65:7: warning: symbol 'cavium_rng_remove' was not declared. Should it be static? Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
This patch updates the safexcel_hmac_init_pad() function to also wait for completion when the digest return code is -EBUSY, as it would mean the request is in the backlog to be processed later. Fixes: 1b44c5a6 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Suggested-by: NOfer Heifetz <oferh@marvell.com> Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
In heavy traffic the DMA mapping is overwritten by multiple requests as the DMA address is stored in a global context. This patch moves this information to the per-hash request context so that it can't be overwritten. Fixes: 1b44c5a6 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Ofer Heifetz 提交于
In heavy traffic the DMA mapping is overwritten by multiple requests as the DMA address is stored in a global context. This patch moves this information to the per-hash request context so that it can't be overwritten. Fixes: 1b44c5a6 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: NOfer Heifetz <oferh@marvell.com> [Antoine: rebased the patch, small fixes, commit message.] Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 03 3月, 2018 8 次提交
-
-
由 Brijesh Singh 提交于
Commit 1d57b17c ("crypto: ccp: Define SEV userspace ioctl and command id") added the invalid length enum but we missed capitalizing it. Fixes: 1d57b17c (crypto: ccp: Define SEV userspace ioctl ...) Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> CC: Gary R Hook <gary.hook@amd.com> Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com> Acked-by: NGary R Hook <gary.hook@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Brijesh Singh 提交于
Fix sparse warning: Using plain integer as NULL pointer. Replaces assignment of 0 to pointer with NULL assignment. Fixes: 200664d5 (Add Secure Encrypted Virtualization ...) Cc: Borislav Petkov <bp@suse.de> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Gary Hook <gary.hook@amd.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com> Acked-by: NGary R Hook <gary.hook@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Maciej S. Szmigiero 提交于
rsa-pkcs1pad uses a value returned from a RSA implementation max_size callback as a size of an input buffer passed to the RSA implementation for encrypt and sign operations. CCP RSA implementation uses a hardware input buffer which size depends only on the current RSA key length, so it should return this key length in the max_size callback, too. This also matches what the kernel software RSA implementation does. Previously, the value returned from this callback was always the maximum RSA key size the CCP hardware supports. This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd() tried to copy this large input buffer into a RSA key length-sized hardware input buffer. Signed-off-by: NMaciej S. Szmigiero <mail@maciej.szmigiero.name> Fixes: ceeec0af ("crypto: ccp - Add support for RSA on the CCP") Cc: stable@vger.kernel.org Acked-by: NGary R Hook <gary.hook@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
I don't why we need take a single write lock and disable interrupts while setting up debugfs. This is what what happens when we try anyway: |ccp 0000:03:00.2: enabling device (0000 -> 0002) |BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:69 |in_atomic(): 1, irqs_disabled(): 1, pid: 3, name: kworker/0:0 |irq event stamp: 17150 |hardirqs last enabled at (17149): [<0000000097a18c49>] restore_regs_and_return_to_kernel+0x0/0x23 |hardirqs last disabled at (17150): [<000000000773b3a9>] _raw_write_lock_irqsave+0x1b/0x50 |softirqs last enabled at (17148): [<0000000064d56155>] __do_softirq+0x3b8/0x4c1 |softirqs last disabled at (17125): [<0000000092633c18>] irq_exit+0xb1/0xc0 |CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0-rc2+ #30 |Workqueue: events work_for_cpu_fn |Call Trace: | dump_stack+0x7d/0xb6 | ___might_sleep+0x1eb/0x250 | down_write+0x17/0x60 | start_creating+0x4c/0xe0 | debugfs_create_dir+0x9/0x100 | ccp5_debugfs_setup+0x191/0x1b0 | ccp5_init+0x8a7/0x8c0 | ccp_dev_init+0xb8/0xe0 | sp_init+0x6c/0x90 | sp_pci_probe+0x26e/0x590 | local_pci_probe+0x3f/0x90 | work_for_cpu_fn+0x11/0x20 | process_one_work+0x1ff/0x650 | worker_thread+0x1d4/0x3a0 | kthread+0xfe/0x130 | ret_from_fork+0x27/0x50 If any locking is required, a simple mutex will do it. Cc: Gary R Hook <gary.hook@amd.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: NGary R Hook <gary.hook@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Antoine Tenart 提交于
The Atmel AES driver uses memzero_explicit on the keys on error, but the variable zeroed isn't the right one because of a typo. Fix this by using the right variable. Fixes: 89a82ef8 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes") Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com> Reviewed-by: NTudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Rui Miguel Silva 提交于
I.MX7x only use two clocks for the CAAM module, so make sure we do not try to use the mem and the emi_slow clock when running in that imx7d and imx7s machine type. Cc: "Horia Geantă" <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Signed-off-by: NRui Miguel Silva <rui.silva@linaro.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Rui Miguel Silva 提交于
caam_remove already removes the debugfs entry, so we need to remove the one immediately before calling caam_remove. This fix a NULL dereference at error paths is caam_probe fail. Fixes: 67c2315d ("crypto: caam - add Queue Interface (QI) backend support") Tested-by: NRyan Harkin <ryan.harkin@linaro.org> Cc: "Horia Geantă" <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Cc: <stable@vger.kernel.org> # 4.12+ Reviewed-by: NHoria Geantă <horia.geanta@nxp.com> Signed-off-by: NRui Miguel Silva <rui.silva@linaro.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Brijesh Singh 提交于
Paulian reported the below kernel crash on Ryzen 5 system: BUG: unable to handle kernel NULL pointer dereference at 0000000000000073 RIP: 0010:.LC0+0x41f/0xa00 RSP: 0018:ffffa9968003bdd0 EFLAGS: 00010002 RAX: ffffffffb113b130 RBX: 0000000000000000 RCX: 00000000000005a7 RDX: 00000000000000ff RSI: ffff8b46dee651a0 RDI: ffffffffb1bd617c RBP: 0000000000000246 R08: 00000000000251a0 R09: 0000000000000000 R10: ffffd81f11a38200 R11: ffff8b52e8e0a161 R12: ffffffffb19db220 R13: 0000000000000007 R14: ffffffffb17e4888 R15: 5dccd7affc30a31e FS: 0000000000000000(0000) GS:ffff8b46dee40000(0000) knlGS:0000000000000000 CR2: 0000000000000073 CR3: 000080128120a000 CR4: 00000000003406e0 Call Trace: ? sp_get_psp_master_device+0x56/0x80 ? map_properties+0x540/0x540 ? psp_pci_init+0x20/0xe0 ? map_properties+0x540/0x540 ? sp_mod_init+0x16/0x1a ? do_one_initcall+0x4b/0x190 ? kernel_init_freeable+0x19b/0x23c ? rest_init+0xb0/0xb0 ? kernel_init+0xa/0x100 ? ret_from_fork+0x22/0x40 Since Ryzen does not support PSP/SEV firmware hence i->psp_data will NULL in all sp instances. In those cases, 'i' will point to the list head after list_for_each_entry(). Dereferencing the head will cause kernel crash. Add check to call get master device only when PSP/SEV is detected. Reported-by: NPaulian Bogdan Marinca <paulian@marinca.net> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> CC: Gary R Hook <gary.hook@amd.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: NBrijesh Singh <brijesh.singh@amd.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-