03 Dec, 2020
2 commits
-
TRNG "sample size" (the total number of entropy samples that will be taken
during entropy generation) default / POR value is very conservatively
set to 2500.Let's set it to 512, the same as the caam driver in U-boot
(drivers/crypto/fsl_caam.c) does.This solves the issue of RNG performance dropping after a suspend/resume
cycle on parts where caam loses power, since the initial U-boot setttings
are lost and kernel does not restore them when resuming.Note: when changing the sample size, the self-test parameters need to be
updated accordingly.Signed-off-by: Horia Geantă
Reviewed-by: Iuliana Prodan -
Remove read of rtmctl register, which is not needed after
commit 8439e94fceb3 ("crypto: caam - fix sparse warnings").Fixes: 8439e94fceb3 ("crypto: caam - fix sparse warnings")
Signed-off-by: Horia Geantă
Reviewed-by: Iuliana Prodan
02 Dec, 2020
2 commits
-
The following stack trace is met when stress-testing suspend/resume:
[...]
PM: suspend devices took 1.972 seconds
[...]
SError Interrupt on CPU1, code 0xbf000002 -- SError
CPU: 1 PID: 213 Comm: hwrng Not tainted 5.4.70-2.3.0+g72209dedd129 #1
Hardware name: Freescale i.MX8DXL EVK (DT)
pstate: 60000005 (nZCv daif -PAN -UAO)
pc : _raw_spin_unlock_bh+0x0/0x28
lr : caam_jr_enqueue+0x24c/0x378
sp : ffff8000127dbd10
x29: ffff8000127dbd10 x28: ffff00003cac5940
x27: 00000000bcb5ef80 x26: 0000000000000010
x25: ffff800011c12000 x24: ffff8000127dbdb8
x23: ffff800010ca2298 x22: ffff00003c8aec10
x21: ffff00003cb5ef80 x20: 00000000ffffff8d
x19: 0000000000000010 x18: 000000000000000e
x17: 0000000000000001 x16: 0000000000000019
x15: 0000000000000033 x14: 000000000000004c
x13: 0000000000000068 x12: ffff800011188e90
x11: ffff00003c897210 x10: 0000000000000026
x9 : 00000000a4dcb313 x8 : 0000000000000000
x7 : 0000000000000001 x6 : ffff800011b59000
x5 : 0000000000000000 x4 : 0000000000000001
x3 : 0000000000000004 x2 : 0000000000000014
x1 : 00000000000001ec x0 : ffff00003cac5940
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 1 PID: 213 Comm: hwrng Not tainted 5.4.70-2.3.0+g72209dedd129 #1
Hardware name: Freescale i.MX8DXL EVK (DT)
Call trace:
dump_backtrace+0x0/0x140
show_stack+0x14/0x20
dump_stack+0xb4/0x114
panic+0x158/0x324
nmi_panic+0x84/0x88
arm64_serror_panic+0x74/0x80
do_serror+0x80/0x138
el1_error+0x84/0xf8
_raw_spin_unlock_bh+0x0/0x28
caam_rng_read_one.isra.0+0x1c8/0x3a0
caam_read+0x80/0xa8
hwrng_fillfn+0x8c/0x140
kthread+0x138/0x158
ret_from_fork+0x10/0x1c
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x0002,20002008
Memory Limit: noneThis happens when:
-the generic "hwrng" kthread tries to draw entropy and
-the current rng is caam's rng and
-the job ring used for caam rng hasn't been resumed yet
(after a suspend)The issue has been noticed also in upstream (for TPM device in ChromeOS)
and the fix proposed involved making the "hwrng" kthread freezable:
03a3bb7ae631 ("hwrng: core - Freeze khwrng thread during suspend")
ff296293b353 ("random: Support freezable kthreads in add_hwgenerator_randomness()")
59b569480dc8 ("random: Use wait_event_freezable() in add_hwgenerator_randomness()")However, because these commits introduced a regression in virtio-rng
(Link: https://lore.kernel.org/lkml/4a45b3e0-ed3a-61d3-bfc6-957c7ba631bb@maciej.szmigiero.name)
they were later reverted in commit
08e97aec700a ("Revert "hwrng: core - Freeze khwrng thread during suspend"")Since there was no progress in upstream and fixing virtio-rng regression
is not trivial, the solution chosen is to unregister / re-register
caam rng driver from hwrng during suspend / resume.Signed-off-by: Horia Geantă
Tested-by: Iuliana Prodan -
The global driver_data.jr_list contains the list of active job rings
at a given moment.Picking a JR is done using caam_jr_alloc(), which goes through this list
and chooses the JR with the least number of users ("tfm_count").During the JR suspend/resume, this list must be updated to reflect that
the JR is no longer available - otherwise caam_jr_alloc() could return
a JR that has been suspended.While this is rather a theoretical issue (i.e. was not met in practice),
it is a prerequisite for fixing the RNG failure met during suspend/resume.Signed-off-by: Horia Geantă
Tested-by: Iuliana Prodan
08 Oct, 2020
1 commit
-
* tag 'v5.4.70': (3051 commits)
Linux 5.4.70
netfilter: ctnetlink: add a range check for l3/l4 protonum
ep_create_wakeup_source(): dentry name can change under you...
...Conflicts:
arch/arm/mach-imx/pm-imx6.c
arch/arm64/boot/dts/freescale/imx8mm-evk.dts
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
drivers/crypto/caam/caamalg.c
drivers/gpu/drm/imx/dw_hdmi-imx.c
drivers/gpu/drm/imx/imx-ldb.c
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/enetc/enetc.c
drivers/net/ethernet/freescale/enetc/enetc_pf.c
drivers/thermal/imx_thermal.c
drivers/usb/cdns3/ep0.c
drivers/xen/swiotlb-xen.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.cSigned-off-by: Jason Liu
01 Oct, 2020
2 commits
-
[ Upstream commit 9195189e00a7db55e7d448cee973cae87c5a3c71 ]
The libkcapi test which causes kernel panic is
aead asynchronous vmsplice multiple test../bin/kcapi -v -d 4 -x 10 -c "ccm(aes)"
-q 4edb58e8d5eb6bc711c43a6f3693daebde2e5524f1b55297abb29f003236e43d
-t a7877c99 -n 674742abd0f5ba -k 2861fd0253705d7875c95ba8a53171b4
-a fb7bc304a3909e66e2e0c5ef952712dd884ce3e7324171369f2c5db1adc48c7dThis patch avoids dma_mapping of a zero length sg which causes the panic,
by using sg_nents_for_len which maps only upto a specific lengthSigned-off-by: Ayush Sawal
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin -
[ Upstream commit 9ed498c6280a2f2b51d02df96df53037272ede49 ]
sk->sk_backlog.tail might be read without holding the socket spinlock,
we need to add proper READ_ONCE()/WRITE_ONCE() to silence the warnings.KCSAN reported :
BUG: KCSAN: data-race in tcp_add_backlog / tcp_recvmsg
write to 0xffff8881265109f8 of 8 bytes by interrupt on cpu 1:
__sk_add_backlog include/net/sock.h:907 [inline]
sk_add_backlog include/net/sock.h:938 [inline]
tcp_add_backlog+0x476/0xce0 net/ipv4/tcp_ipv4.c:1759
tcp_v4_rcv+0x1a70/0x1bd0 net/ipv4/tcp_ipv4.c:1947
ip_protocol_deliver_rcu+0x4d/0x420 net/ipv4/ip_input.c:204
ip_local_deliver_finish+0x110/0x140 net/ipv4/ip_input.c:231
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
ip_local_deliver+0x133/0x210 net/ipv4/ip_input.c:252
dst_input include/net/dst.h:442 [inline]
ip_rcv_finish+0x121/0x160 net/ipv4/ip_input.c:413
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
ip_rcv+0x18f/0x1a0 net/ipv4/ip_input.c:523
__netif_receive_skb_one_core+0xa7/0xe0 net/core/dev.c:4929
__netif_receive_skb+0x37/0xf0 net/core/dev.c:5043
netif_receive_skb_internal+0x59/0x190 net/core/dev.c:5133
napi_skb_finish net/core/dev.c:5596 [inline]
napi_gro_receive+0x28f/0x330 net/core/dev.c:5629
receive_buf+0x284/0x30b0 drivers/net/virtio_net.c:1061
virtnet_receive drivers/net/virtio_net.c:1323 [inline]
virtnet_poll+0x436/0x7d0 drivers/net/virtio_net.c:1428
napi_poll net/core/dev.c:6311 [inline]
net_rx_action+0x3ae/0xa90 net/core/dev.c:6379
__do_softirq+0x115/0x33f kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0xbb/0xe0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
do_IRQ+0xa6/0x180 arch/x86/kernel/irq.c:263
ret_from_intr+0x0/0x19
native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x1af/0x280 kernel/sched/idle.c:263
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
start_secondary+0x208/0x260 arch/x86/kernel/smpboot.c:264
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241read to 0xffff8881265109f8 of 8 bytes by task 8057 on cpu 0:
tcp_recvmsg+0x46e/0x1b40 net/ipv4/tcp.c:2050
inet_recvmsg+0xbb/0x250 net/ipv4/af_inet.c:838
sock_recvmsg_nosec net/socket.c:871 [inline]
sock_recvmsg net/socket.c:889 [inline]
sock_recvmsg+0x92/0xb0 net/socket.c:885
sock_read_iter+0x15f/0x1e0 net/socket.c:967
call_read_iter include/linux/fs.h:1889 [inline]
new_sync_read+0x389/0x4f0 fs/read_write.c:414
__vfs_read+0xb1/0xc0 fs/read_write.c:427
vfs_read fs/read_write.c:461 [inline]
vfs_read+0x143/0x2c0 fs/read_write.c:446
ksys_read+0xd5/0x1b0 fs/read_write.c:587
__do_sys_read fs/read_write.c:597 [inline]
__se_sys_read fs/read_write.c:595 [inline]
__x64_sys_read+0x4c/0x60 fs/read_write.c:595
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 8057 Comm: syz-fuzzer Not tainted 5.4.0-rc6+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
30 Sep, 2020
10 commits
-
Use dev_* instead of pr_*.
Print random buffer only when debugging.Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
In order to follow recommendation in SP800-90C (section "9.4 The
Oversampling-NRBG Construction") limit the output of "generate" JD
submitted to CAAM. See
https://lore.kernel.org/linux-crypto/VI1PR0402MB3485EF10976A4A69F90E5B0F98580@VI1PR0402MB3485.eurprd04.prod.outlook.com/
for more details.This change should make CAAM's hwrng driver good enough to have 1024
quality rating.Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu
(cherry picked from commit ea53756d831a1a5db3ca00a12747365e2fcb4bd8)
Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
Instantiate CAAM RNG with prediction resistance enabled to improve its
quality (with PR on DRNG is forced to reseed from TRNG every time
random data is generated).Management Complex firmware with version lower than 10.20.0
doesn't provide prediction resistance support. Consider this
and only instantiate rng when mc f/w version is lower.Signed-off-by: Andrey Smirnov
Signed-off-by: Andrei Botila
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Reviewed-by: Horia Geantă
Signed-off-by: Herbert Xu
(cherry picked from commit 358ba762d9f1d4ba99ab31ef12bc28014b22f4c9)Fix merge conflicts caused by i.MX BSP
commit d8ec539192a6 ("LF-292-1 crypto: caam - refactor RNG initialization")Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
In order to make sure that we always use non-stale entropy data, change
the code to invalidate entropy register during RNG initialization.Signed-off-by: Aymen Sghaier
Signed-off-by: Vipul Kumar
[andrew.smirnov@gmail.com ported to upstream kernel, rewrote commit msg]
Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu
(cherry picked from commit 551ce72a78e2c5493fa987410437e54b5f3fdd34)
Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
We shouldn't stay silent if RNG job fails. Add appropriate code to
check for that case and propagate error code up appropriately.Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu
(cherry picked from commit 32107e43b505de44ebe1917da2c8c6229acbd509)In case of read() failing (and thus real_len being negative),
don't print the buffer since print_hex_dump() interprets the length
as an unsigned.Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
Rework CAAM RNG implementation as follows:
- Make use of the fact that HWRNG supports partial reads and will
handle such cases gracefully by removing recursion in caam_read()- Convert blocking caam_read() codepath to do a single blocking job
read directly into requested buffer, bypassing any intermediary
buffers- Convert async caam_read() codepath into a simple single
reader/single writer FIFO use-case, thus simplifying concurrency
handling and delegating buffer read/write position management to KFIFO
subsystem.- Leverage the same low level RNG data extraction code for both async
and blocking caam_read() scenarios, get rid of the shared job
descriptor and make non-shared one as a simple as possible (just
HEADER + ALGORITHM OPERATION + FIFO STORE)- Split private context from DMA related memory, so that the former
could be allocated without GFP_DMA.NOTE: On its face value this commit decreased throughput numbers
reported bydd if=/dev/hwrng of=/dev/null bs=1 count=100K [iflag=nonblock]
by about 15%, however commits that enable prediction resistance and
limit JR total size impact the performance so much and move the
bottleneck such as to make this regression irrelevant.NOTE: On the bright side, this commit reduces RNG in kernel DMA buffer
memory usage from 2 x RN_BUF_SIZE (~256K) to 32K.Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu
(cherry picked from commit 2c5e88dc90f50022d1b4bf56c9b45d4162757094)Since now CAAM RNG is configured as a TRNG, in order to avoid lengthy
self-tests, limit the random bytes read by the test from ~ 64K / 128K
to 32, 64, 128 bytes - values that are in line with hw_random API
(see .read callback in "struct hwrng").Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
Leverage devres to get rid of code storing global context as well as
init_done flag.Original code also has a circular deallocation dependency where
unregister_algs() -> caam_rng_exit() -> caam_jr_free() chain would
only happen if all of JRs were freed. Fix this by moving
caam_rng_exit() outside of unregister_algs() and doing it specifically
for JR that instantiated HWRNG.Signed-off-by: Andrey Smirnov
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Reviewed-by: Horia Geantă
Signed-off-by: Herbert Xu
(cherry picked from commit 1517f63cd84f00da3a3e21dff042410b2799c1c3)Replace global context (caam_rng) with ctx->rng for self-tests.
Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
Make caamrng code a bit more symmetric by moving initialization code
to .init hook of struct hwrng.Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu
(cherry picked from commit 8483c831b9f3fca2219ac45f361386a1233f6c9b)Run self-test after registering to hwrng framework, since
hwrng.init=caam_init() callback must run prior to the self-test.Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
Be consistent with the rest of the codebase and use GFP_DMA when
allocating memory for a CAAM JR descriptor.Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Cc: Chris Healy
Cc: Lucas Stach
Cc: Horia Geantă
Cc: Herbert Xu
Cc: Iuliana Prodan
Cc: linux-imx@nxp.com
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu
(cherry picked from commit f0ac02c791a178df807c0a079a2372b8d825652b)
Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND -
This reverts commit 8935c53d9f24e3e7c7177088cd3b38e11c4b37b8.
This internal commit is being deprecated in favour of upstream
commit 551ce72a78e2 ("crypto: caam - invalidate entropy register during RNG initialization")Signed-off-by: Horia Geantă
Reviewed-by: Franck LENORMAND
10 Sep, 2020
1 commit
-
Added suspend/resume operations for PM support in the DCP driver.
After a suspend/resume cycle DCP would still be in a low-power mode
and have its clocks gated, thus requiring state to be saved beforehand:
- Control register value(DCP_CTRL)
- Channel control register value(DCP_CHANNELCTRL)Signed-off-by: Dragos Rosioru
Reviewed-by: Horia Geantă
01 Sep, 2020
4 commits
-
Validate sizes for each argument received from user-space
to avoid untrusted values.
Therefor check if Encrypted Key Type, Key Mode and Key Value
are given - their sizes must be at least 1 since they have
the null terminator.Reported-by: Coverity 10893160
Signed-off-by: Iuliana Prodan
Reviewed-by: Franck LENORMAND -
Add null terminator to temporary buffer used to copy from
user-space data needed for key generation.
This buffer is later used in operations (i.e. strlen()) that
expects properly null-terminated strings.
Therefore add the null terminator character.Reported-by: Coverity 10893158
Signed-off-by: Iuliana Prodan
Reviewed-by: Franck LENORMAND -
The address of an array is never NULL, so the comparison of
black key array always evaluate the same way.
Remove unnecessary check.Reported-by: Coverity 10893157
Signed-off-by: Iuliana Prodan
Reviewed-by: Franck LENORMAND -
The address of an array is never NULL, so the comparison of
black key array always evaluate the same way.
Remove unnecessary check.Reported-by: Coverity 10893156
Signed-off-by: Iuliana Prodan
Reviewed-by: Franck LENORMAND
21 Aug, 2020
5 commits
-
Update job descriptors for black key generation and blob encapsulation/
decapsulation with inline commands.
For LOAD commands use immediate values instead of pointers because
this is the fastest and the most efficient of the transfer mechanisms.Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă -
Tagged object header was added to have red key (plaintext)
length available for blob decapsulation.Fixes: 60baeafa838f ("MLK-24420-3 crypto: caam - add ioctl calls for black keys and blobs generation")
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă -
For black key encapsulation and decapsulation into/from a black blob,
for both ECB and CCM, use red key length as input.For blob encapsulation a randomly-generated, 256-bit blob key is used to
encrypt the data using the AES-CCM cryptographic algorithm.
Therefore, blob size needs to be computed based on CCM key size
- padded as necessary so the key is a multiple of 8 bytes long
and add 6-byte nonce and 6-byte ICV.Fixes: 84287c5d3b80 ("MLK-24420-2 crypto: caam - add support for black keys and blobs")
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă -
Add red key length to tag object in order to have the plaintext
information available for both keys and blobs. This is used to
encrypt a red key into a black key and to decapsulate a
black key from a black blob.
While here, I've simplified the tagged object API by removing some
redundant functions.Fixes: 04cab5a13d93 ("MLK-24420-1 crypto: caam - update tagged keys functionality and tk transformations for skcipher")
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă -
[ Upstream commit eeedb618378f8a09779546a3eeac16b000447d62 ]
The arc4 algorithm requires storing state in the request context
in order to allow more than one encrypt/decrypt operation. As this
driver does not seem to do that, it means that using it for more
than one operation is broken.Fixes: eaed71a44ad9 ("crypto: caam - add ecb(*) support")
Link: https://lore.kernel.org/linux-crypto/CAMj1kXGvMe_A_iQ43Pmygg9xaAM-RLy=_M=v+eg--8xNmv9P+w@mail.gmail.com
Link: https://lore.kernel.org/linux-crypto/20200702101947.682-1-ardb@kernel.org
Signed-off-by: Herbert Xu
Acked-by: Ard Biesheuvel
Acked-by: Horia Geantă
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
19 Aug, 2020
5 commits
-
commit 9e27c99104707f083dccd3b4d79762859b5a0614 upstream.
There is this call chain:
cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc
where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
was not specified.Signed-off-by: Mikulas Patocka
Cc: stable@vger.kernel.org # v4.11+
Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT")
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 8a302808c60d441d9884cb00ea7f2b534f2e3ca5 upstream.
Running the crypto manager self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
when using the ccp-crypto driver:alg: skcipher: cbc-des3-ccp encryption failed on test vector 0; expected_error=0, actual_error=-5 ...
alg: skcipher: ctr-aes-ccp decryption overran dst buffer on test vector 0 ...
alg: ahash: sha224-ccp test failed (wrong result) on test vector ...
These errors are the result of improper processing of scatterlists mapped
for DMA.Given a scatterlist in which entries are merged as part of mapping the
scatterlist for DMA, the DMA length of a merged entry will reflect the
combined length of the entries that were merged. The subsequent
scatterlist entry will contain DMA information for the scatterlist entry
after the last merged entry, but the non-DMA information will be that of
the first merged entry.The ccp driver does not take this scatterlist merging into account. To
address this, add a second scatterlist pointer to track the current
position in the DMA mapped representation of the scatterlist. Both the DMA
representation and the original representation of the scatterlist must be
tracked as while most of the driver can use just the DMA representation,
scatterlist_map_and_copy() must use the original representation and
expects the scatterlist pointer to be accurate to the original
representation.In order to properly walk the original scatterlist, the scatterlist must
be walked until the combined lengths of the entries seen is equal to the
DMA length of the current entry being processed in the DMA mapped
representation.Fixes: 63b945091a070 ("crypto: ccp - CCP device driver and interface support")
Signed-off-by: John Allen
Cc: stable@vger.kernel.org
Acked-by: Tom Lendacky
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit c06c76602e03bde24ee69a2022a829127e504202 upstream.
clang static analysis flags this error
qat_uclo.c:297:3: warning: Attempt to free released memory
[unix.Malloc]
kfree(*init_tab_base);
^~~~~~~~~~~~~~~~~~~~~When input *init_tab_base is null, the function allocates memory for
the head of the list. When there is problem allocating other list
elements the list is unwound and freed. Then a check is made if the
list head was allocated and is also freed.Keeping track of the what may need to be freed is the variable 'tail_old'.
The unwinding/freeing block iswhile (tail_old) {
mem_init = tail_old->next;
kfree(tail_old);
tail_old = mem_init;
}The problem is that the first element of tail_old is also what was
allocated for the list headinit_header = kzalloc(sizeof(*init_header), GFP_KERNEL);
...
*init_tab_base = init_header;
flag = 1;
}
tail_old = init_header;So *init_tab_base/init_header are freed twice.
There is another problem.
When the input *init_tab_base is non null the tail_old is calculated by
traveling down the list to first non null entry.tail_old = init_header;
while (tail_old->next)
tail_old = tail_old->next;When the unwinding free happens, the last entry of the input list will
be freed.So the freeing needs a general changed.
If locally allocated the first element of tail_old is freed, else it
is skipped. As a bit of cleanup, reset *init_tab_base if it came in
as null.Fixes: b4b7e67c917f ("crypto: qat - Intel(R) QAT ucode part of fw loader")
Cc:
Signed-off-by: Tom Rix
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 5ead051780404b5cb22147170acadd1994dc3236 upstream.
There is this call chain:
sec_alg_skcipher_encrypt -> sec_alg_skcipher_crypto ->
sec_alg_alloc_and_calc_split_sizes -> kcalloc
where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
was not specified.Signed-off-by: Mikulas Patocka
Cc: stable@vger.kernel.org # v4.19+
Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
Acked-by: Jonathan Cameron
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 9bc6165d608d676f05d8bf156a2c9923ee38d05b ]
Fix a small resource leak on the error path of cipher processing.
Signed-off-by: Gilad Ben-Yossef
Fixes: 63ee04c8b491e ("crypto: ccree - add skcipher support")
Cc: Markus Elfring
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
14 Aug, 2020
1 commit
-
caam snvs clock is optional, as mentioned in
commit b696cc4048ff ("dt-bindings: crypto: fsl: add clock for caam snvs")Sync the driver with DT binding doc and avoid
the gratuitous error message.Signed-off-by: Horia Geantă
Reviewed-by: Franck Lenormand
13 Aug, 2020
3 commits
-
This patch adds the Kernel support for the caam-keygen user-space
application. It has two IOCTL calls for key and blob generation and
import a black key from a blob.This support is included in CRYPTO_DEV_FSL_CAAM_TK_API (tagged key
support).Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă -
CAAM's Black Key mechanism is intended for protection
of user keys against bus snooping. This automatically
encapsulates and decapsulates cryptographic keys ''on-the-fly''
in an encrypted data structure called a Black Key.
Before a value is copied from a Key Register to memory,
CAAM will automatically encrypt the key as a Black Key
(encrypted key) using the current value in the JDKEKR or
TDKEKR as the encryption key.CAAM's built-in Blob Protocol provides a method for protecting
user-defined data across system power cycles. CAAM protects data
in a data structure called a Blob, which provides both confidentiality
and integrity protection. The data to be protected is encrypted so that
it can be safely placed into non-volatile storage before the SoC is
powered down.This patch includes the support to generate a black key from random or
from a plaintext. Also one can encapsulate it into a blob or decapsulate
a black key from a blob.
The key and blob generation descriptors are exported into a separate file,
such that they could be shared with other interfaces (qi, qi2).This feature has support only for black keys, encapsulated in
black blobs in General Memory.In caamkeyblob_test.c file is a test that validates the above
operations: create a black key from plaintext or from random,
encapsulate and decapsulate a blob and compare the obtained black key.
This test is configured as a kernel module.Signed-off-by: Franck LENORMAND
Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă -
Tagged keys are keys that contain metadata indicating what
they are and how to handle them using the new added tag_object API.
A tag object represents the metadata (or simply a header/configuration)
and the actual data (e.g. black key) obtained from hardware.
The support, for tagged keys, to skcipher algorithms, is done by
adding new transformations, with tk prefix to distinguish
between plaintext and tagged keys.
The tk_ transformations can be used directly by their name:
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "skcipher", /* this selects the symmetric cipher */
.salg_name = "tk(cbc(aes))" /* this is the cipher name */
};
or for dm-crypt, e.g. using dmsetup:
dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10)
crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1
sector_size:512".
tk_ transformations will know how to handle tagged keys, by loading the
proper settings for KEY command.The API expects that the object (the actual data) from a tag object
to be a buffer (defined by address and size).Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
05 Aug, 2020
1 commit
-
[ Upstream commit 128c66429247add5128c03dc1e144ca56f05a4e2 ]
Release all allocated memory if sha type is invalid:
In ccp_run_sha_cmd, if the type of sha is invalid, the allocated
hmac_buf should be released.v2: fix the goto.
Signed-off-by: Navid Emamdoost
Acked-by: Gary R Hook
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
22 Jul, 2020
2 commits
-
commit aee1f9f3c30e1e20e7f74729ced61eac7d74ca68 upstream.
If CRYPTO_DEV_ATMEL_AUTHENC is m, CRYPTO_DEV_ATMEL_SHA is m,
but CRYPTO_DEV_ATMEL_AES is y, building will fail:drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_init_tfm':
atmel-aes.c:(.text+0x670): undefined reference to `atmel_sha_authenc_get_reqsize'
atmel-aes.c:(.text+0x67a): undefined reference to `atmel_sha_authenc_spawn'
drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_setkey':
atmel-aes.c:(.text+0x7e5): undefined reference to `atmel_sha_authenc_setkey'Make CRYPTO_DEV_ATMEL_AUTHENC depend on CRYPTO_DEV_ATMEL_AES,
and select CRYPTO_DEV_ATMEL_SHA and CRYPTO_AUTHENC for it under there.Reported-by: Hulk Robot
Suggested-by: Herbert Xu
Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...")
Signed-off-by: YueHaibing
Reviewed-by: Tudor Ambarus
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit d158367682cd822aca811971e988be6a8d8f679f upstream.
The following error is raised when CONFIG_CRYPTO_DEV_ATMEL_AES=y and
CONFIG_CRYPTO_DEV_ATMEL_AUTHENC=m:
drivers/crypto/atmel-aes.o: In function `atmel_aes_authenc_setkey':
atmel-aes.c:(.text+0x9bc): undefined reference to `crypto_authenc_extractkeys'
Makefile:1094: recipe for target 'vmlinux' failedFix it by moving the selection of CRYPTO_AUTHENC under
config CRYPTO_DEV_ATMEL_AES.Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...")
Signed-off-by: Tudor Ambarus
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman
24 Jun, 2020
1 commit
-
[ Upstream commit 281c377872ff5d15d80df25fc4df02d2676c7cde ]
The current implementation of the multiple accelerator core support for
OMAP SHA does not work properly. It always picks up the first probed
accelerator core if this is available, and rest of the book keeping also
gets confused if there are two cores available. Add proper load
balancing support for SHA, and also fix any bugs related to the
multicore support while doing it.Signed-off-by: Tero Kristo
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin
