-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl+ahE8ACgkQONu9yGCS
aT4j1A/9HzkKKoqZ2vXYQ1/uEnUqZech9ly1KxpNTBrSZYAtx3MaWY7tGDEx2BqD
y6iw9x4MymhHEbpwLg6YmmdWuMQLNNYJGoyLiPJgWhkE4c7zHadhNz1DcPEI8F7z
bSlUJ3Oebr8gzv0FvUmeVXw7Z2EuOqM1zGgTAZfnKY3DkYHbLnrzUJ4AiI8TNeba
pPIhjfIJ1TvhF+s5ggf2m8OtSWLZ0doCWCPmCFe2WyERX2WYCzPgsm0yL7L7oXME
ZqWpOcClBsiYekBNcZ4kxozhJtArCnv24n9VoXJ/YJIlWKvCA6uC8r527nGN/z08
dfFelj1nDs7/VrCSP4+109EjxLQnSYGgIWP0g0OsC+9wOmrQsYJ1azP1eNjm+NuC
hPa8uYVEZxwVyJuEfu4ZB4NMZBlD2qnHoskvBKbyZ8yaVnbvlMp552XMwsmJBpCs
8wArzabrJEz396LUUIYG829D7NBDuRav1Miu+FTzlbn+xZ/Y/S8OmhoG2stWa4wV
y5x0M0DWgrqiZ9rMkz9A03UNnCInQVTfIBoMl63xFitW4/0vLsln3+CjzlKm7H46
rD/tKACUoCDjR5DN+JwQzmTdL9zBb4p1cXwWjWb6rON3BkXmO0JVAxzurxI9PfX0
ZWDydZ3HNmrm0d3J12zf3kTX56PfPFAGWUsEc4Ntb5zdWXSQJsE=
=fZ3T
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdQaENiSDAlGTDEbB7G51OISzHs0FAl+bPfIACgkQ7G51OISz
Hs1LaA/9GOp34DrKBM/z7eN7gcbU4rJUhnggZ3vCXShRs3vtjEJ7wptzJb7lErXX
6JCS/OjZpQpZJcHdBX0Kxovf8LVgvDrsbAhRhQkdFr0dESQQ4UY+vT5me9Y9Ot1F
biG2z2HduLAxBgrYB2uA7VeRqlLiAa7ELS5EWB90xjY49w7gy5kK7AFrBRQdme9G
r4fY89RD9sJVzo4sxgQwUYXuNJi5OmwbN+wrkwk8HXyL0tAB9SNQJ7A962Gxamao
AIXT0CvNpNSkR/4JeqDXbJu54fMZxaF4A7a9mgL42fWe45jQs2zYSNx3vdZskzK8
8z+4FCmShNkGMMLV5k6Ds/lJ8uF1yOkUBJJeiHJxnpZw93xKVWZfOVmgm+WO/mNq
POmJVfALFFzwvNllyMX8D++0yhORunzfhzQyKgVAthwmScGQ5TK0cerwAa9VEz1T
40e7AqsNKUxRPnoZYQwM0Y2Vskn6qZ8pOW3rSSQx2YI2lhQHGeUMAugHzYivERkF
8d5hDPaQgfJXmS+S8Xp45zafeMDjoNQFQhZLAptmoF9+NGXdJduPSPJxQ0R/29GT
2LEHNsneGotslpXwluk8x2VlXryf/7okEdR7RLq9kjEyM5BGOc2wcZrD6GXvnAf0
JorbYZPriCaNHrGDdEiRFZmRlKaiR4CbcR3JtYkFJebirmIc1N0=
=8w9z
-----END PGP SIGNATURE-----
Merge tag 'v5.4.73' into 5.4-2.2.x-imx
This is the 5.4.73 stable release
Conflicts:
- arch/arm/boot/dts/imx6sl.dtsi:
Commit [a1767c9019] in NXP tree is now covered with commit [5c4c2f437c]
from upstream.
- drivers/gpu/drm/mxsfb/mxsfb_drv.c:
Resolve merge hunk for patch [ed8b90d303] from upstream
- drivers/media/i2c/ov5640.c:
Patch [aa4bb8b883] in NXP tree is now covered by patches [79ec0578c7]
and [b2f8546056] from upstream. Changes from NXP patch [99aa4c8c18] are
covered in upstream version as well.
- drivers/net/ethernet/freescale/fec_main.c:
Fix merge fuzz for patch [9e70485b40] from upstream.
- drivers/usb/cdns3/gadget.c:
Keep NXP version of the file, upstream version is not compatible.
- drivers/usb/dwc3/core.c:
- drivers/usb/dwc3/core.h:
Fix merge fuzz of patch [08045050c6] together wth NXP patch [b30e41dc1e]
- sound/soc/fsl/fsl_sai.c:
- sound/soc/fsl/fsl_sai.h:
Commit [2ea70e51eb72a] in NXP tree is now covered with commit [1ad7f52fe6]
from upstream.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
commit 83e8aa9121 upstream.
A hardware limitation exists for CAAM until Era 9 which restricts
the accelerator to IVs with only 8 bytes. When CAAM has a lower era
a fallback is necessary to process 16 bytes IV.
Fixes: b189817cf7 ("crypto: caam/qi - add ablkcipher and authenc algorithms")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl9rJlYACgkQONu9yGCS
aT6WbRAAga6QVKrO6R4NeKk0fPqKQQoQeTK+phBOFA7jAoX/rIRKyob2Si9BwhBA
F77vZ6HIZ7+e/o35JJQYQbffbHYs0ANuS1oHGqe0vgbh+72Viaan6g7lFOhpx8qf
y0YS7q+hw4WLZB0gGlBM7nkPXRiis32IrEVabQW+t8hmT2lWyutY8E2yFAU60tvI
Tvjm2c2pvHEcHz9MrjEd/jIVxMFnIl42FBTx9bGsbDUCDzBwEvPArS4bNioP7EFJ
O+rrGCNvwtiv0DuKzX1UIZzQ88IROmU3ZjsIlgOwla7xJWv4QDgmPfyAyRI48QhH
PAZQmSntz+y+MP6B3z3ZBrxc2Fx0kCDtugn2P9+2RVUEpheANJ293vUgYTKN9Roy
dHdWHFWNTO9IYpIN0cZjc25db4ULdjerWQrKcCr6ZO8+Ep/0mSzx3lkWjfuUP8Hr
L2RD6rAm259OpPq8xhAcJpJvoQLwGxaBHyr4QYUmRgmNVURoqe9Q0MTZuiyGsXhm
rtcNky9WvmyyI1lJgXi4A+vmsIThCHEstEMycgTejfJ4itIVA9e1ctJVVomWULCn
9oNStBJpmHw0myDCohbKNjeO1UX/erdF9NaoGto5bnfIhcSae1YQEjRB8zKmzbg1
DpgC1f7IZ7q53vfrDGsAjInOcuEwAn/Y5JMLJOL4mdA9j3XlX2o=
=Ot99
-----END PGP SIGNATURE-----
Merge tag 'v5.4.67' into 5.4-2.2.x-imx
This is the 5.4.67 stable release
This updates the kernel present in the NXP release imx_5.4.47_2.2.0 to the
latest patchset available from stable korg.
Base stable kernel version present in the NXP BSP release is v5.4.47.
Following conflicts were recorded and resolved:
- arch/arm/mach-imx/pm-imx6.c
NXP version has a different PM vectoring scheme, where the IRAM bottom
half (8k) is used to store IRAM code and pm_info. Keep this version to
be compatible with NXP PM implementation.
- arch/arm64/boot/dts/freescale/imx8mm-evk.dts
- arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
NXP patches kept to provide proper LDO setup:
imx8mm-evk.dts: 975d8ab07267ded741c4c5d7500e524c85ab40d3
imx8mn-ddr4-evk.dts: e8e35fd0e759965809f3dca5979a908a09286198
- drivers/crypto/caam/caamalg.c
Keep NXP version, as it already covers the functionality for the
upstream patch [d6bbd4eea2]
- drivers/gpu/drm/imx/dw_hdmi-imx.c
- drivers/gpu/drm/imx/imx-ldb.c
- drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
Port changes from upstream commit [1a27987101], which extends
component lifetime by moving drm structures allocation/free from
bind() to probe().
- drivers/gpu/drm/imx/imx-ldb.c
Merge patch [1752ab50e8] from upstream to disable both LVDS channels
when Enoder is disabled
- drivers/mmc/host/sdhci-esdhc-imx.c
Fix merge fuzz produced by [6534c897fd].
- drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
Commit d1a00c9bb1 from upstream solves the issue with improper error
reporting when qdisc type support is absent. Upstream version is merged
into NXP implementation.
- drivers/net/ethernet/freescale/enetc/enetc.c
Commit [ce06fcb6a6] from upstream merged,
base NXP version kept
- drivers/net/ethernet/freescale/enetc/enetc_pf.c
Commit [e8b86b4d87] from upstream solves
the kernel panic in case if probing fails. NXP has a clean-up logic
implemented different, where the MDIO remove would be invoked in any
failure case. Keep the NXP logic in place.
- drivers/thermal/imx_thermal.c
Upstream patch [9025a5589c] adds missing
of_node_put call, NXP version has been adapted to accommodate this patch
into the code.
- drivers/usb/cdns3/ep0.c
Manual merge of commit [be8df02707] from
upstream to protect cdns3_check_new_setup
- drivers/xen/swiotlb-xen.c
Port upstream commit cca58a1669 to NXP tree, manual hunk was
resolved during merge.
- sound/soc/fsl/fsl_esai.c
Commit [53057bd4ac] upstream addresses the problem of endless isr in
case if exception interrupt is enabled and tasklet is scheduled. Since
NXP implementation has tasklet removed with commit [2bbe95fe6c],
upstream fix does not match the main implementation, hence we keep the
NXP version here.
- sound/soc/fsl/fsl_sai.c
Apply patch [b8ae2bf5cc] from upstream, which uses FIFO watermark
mask macro.
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
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 <iuliana.prodan@nxp.com>
Reviewed-by: Franck LENORMAND <franck.lenormand@nxp.com>
(cherry picked from commit d7c41169bc8e50f3513ca6c694f3130bbe57aeed)
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 <iuliana.prodan@nxp.com>
Reviewed-by: Franck LENORMAND <franck.lenormand@nxp.com>
(cherry picked from commit b8c49eddfd687e049923ab1e5aca09e2b4160f54)
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 <iuliana.prodan@nxp.com>
Reviewed-by: Franck LENORMAND <franck.lenormand@nxp.com>
(cherry picked from commit 8888926c54e819dd7f5d00bad8abdcb8175e8bf6)
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 <iuliana.prodan@nxp.com>
Reviewed-by: Franck LENORMAND <franck.lenormand@nxp.com>
(cherry picked from commit cd078fac33b60e753886ded2e821ef765a137110)
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 <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Tagged object header was added to have red key (plaintext)
length available for blob decapsulation.
Fixes: 60baeafa83 ("MLK-24420-3 crypto: caam - add ioctl calls for black keys and blobs generation")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
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: 84287c5d3b ("MLK-24420-2 crypto: caam - add support for black keys and blobs")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
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: 04cab5a13d ("MLK-24420-1 crypto: caam - update tagged keys functionality and tk transformations for skcipher")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
caam snvs clock is optional, as mentioned in
commit b696cc4048 ("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ă <horia.geanta@nxp.com>
Reviewed-by: Franck Lenormand <franck.lenormand@nxp.com>
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 <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
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 <franck.lenormand@nxp.com>
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
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 <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
commit 55b3209acb upstream.
For skcipher algorithms, the input, output HW S/G tables
look like this: [IV, src][dst, IV]
Now, we can have 2 conditions here:
- there is no IV;
- src and dst are equal (in-place encryption) and scattered
and the error is an "off-by-one" in the HW S/G table.
This issue was seen with KASAN:
BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018
Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321
CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted
5.6.0-rc1-00165-ge4ef8383-dirty #4
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load4+0x90/0xb0
skcipher_edesc_alloc+0x95c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Allocated by task 321:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
skcipher_edesc_alloc+0x21c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff000022a02800
which belongs to the cache dma-kmalloc-512 of size 512
The buggy address is located 344 bytes inside of
512-byte region [ffff000022a02800, ffff000022a02a00)
The buggy address belongs to the page:
page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400
index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
^
ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 334d37c9e2 ("crypto: caam - update IV using HW support")
Cc: <stable@vger.kernel.org> # v5.3+
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f142b6a7b upstream.
Since in the software implementation of XTS-AES there is
no notion of sector every input length is processed the same way.
CAAM implementation has the notion of sector which causes different
results between the software implementation and the one in CAAM
for input lengths bigger than 512 bytes.
Increase sector size to maximum value on 16 bits.
Fixes: c6415a6016 ("crypto: caam - add support for acipher xts(aes)")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Andrei Botila <andrei.botila@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3a5a9e1ef3 upstream.
HW generates a Data Size error for chacha20 requests that are not
a multiple of 64B, since algorithm state (AS) does not have
the FINAL bit set.
Since updating req->iv (for chaining) is not required,
modify skcipher descriptors to set the FINAL bit for chacha20.
[Note that for skcipher decryption we know that ctx1_iv_off is 0,
which allows for an optimization by not checking algorithm type,
since append_dec_op1() sets FINAL bit for all algorithms except AES.]
Also drop the descriptor operations that save the IV.
However, in order to keep code logic simple, things like
S/G tables generation etc. are not touched.
Cc: <stable@vger.kernel.org> # v5.3+
Fixes: 334d37c9e2 ("crypto: caam - update IV using HW support")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Tested-by: Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's the KASAN report:
BUG: KASAN: use-after-free in ahash_done+0xdc/0x3b8
Read of size 1 at addr ffff00002303f010 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc1-00162-gfcb90d5 #59
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
ahash_done+0xdc/0x3b8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
irq_exit+0x114/0x128
__handle_domain_irq+0x80/0xe0
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x180
cpuidle_enter_state+0xa4/0x490
cpuidle_enter+0x48/0x70
call_cpuidle+0x44/0x70
do_idle+0x304/0x338
cpu_startup_entry+0x24/0x40
rest_init+0xf8/0x10c
arch_call_rest_init+0xc/0x14
start_kernel+0x774/0x7b4
Allocated by task 263:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
ahash_edesc_alloc+0x58/0x1f8
ahash_final_no_ctx+0x94/0x6e8
ahash_final+0x24/0x30
crypto_ahash_op+0x58/0xb0
crypto_ahash_final+0x30/0x40
do_ahash_op+0x2c/0xa0
test_ahash_vec_cfg+0x894/0x9e0
test_hash_vec_cfg+0x6c/0x88
test_hash_vec+0xfc/0x1e0
__alg_test_hash+0x1ac/0x368
alg_test_hash+0xf8/0x1c8
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
save_stack+0x24/0xb0
__kasan_slab_free+0x10c/0x188
kasan_slab_free+0x10/0x18
kfree+0x7c/0x298
ahash_done+0xd4/0x3b8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
The buggy address belongs to the object at ffff00002303f000
which belongs to the cache dma-kmalloc-128 of size 128
The buggy address is located 16 bytes inside of
128-byte region [ffff00002303f000, ffff00002303f080)
The buggy address belongs to the page:
page:fffffe00006c0fc0 refcount:1 mapcount:0 mapping:ffff00093200c000 index:0x0
flags: 0xffff00000000200(slab)
raw: 0ffff00000000200 dead000000000100 dead000000000122 ffff00093200c000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00002303ef00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff00002303ef80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff00002303f000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff00002303f080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff00002303f100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 21b014f038 ("crypto: caam - add crypto_engine support for HASH algorithms")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 63db32e653)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Here's the KASAN report:
BUG: KASAN: use-after-free in aead_crypt_done+0x60/0xd8
Read of size 1 at addr ffff00002303f014 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc1-00162-gfcb90d5 #58
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load1+0x5c/0x68
aead_crypt_done+0x60/0xd8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
irq_exit+0x114/0x128
__handle_domain_irq+0x80/0xe0
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x180
_raw_spin_unlock_irq+0x2c/0x78
finish_task_switch+0xa4/0x2f8
__schedule+0x3a4/0x890
schedule_idle+0x28/0x50
do_idle+0x22c/0x338
cpu_startup_entry+0x24/0x40
rest_init+0xf8/0x10c
arch_call_rest_init+0xc/0x14
start_kernel+0x774/0x7b4
Allocated by task 263:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
aead_edesc_alloc+0x1b4/0xbf0
ipsec_gcm_encrypt+0xd4/0x140
crypto_aead_encrypt+0x50/0x68
test_aead_vec_cfg+0x498/0xec0
test_aead_vec+0x110/0x200
alg_test_aead+0xfc/0x680
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
save_stack+0x24/0xb0
__kasan_slab_free+0x10c/0x188
kasan_slab_free+0x10/0x18
kfree+0x7c/0x298
aead_crypt_done+0x58/0xd8
caam_jr_dequeue+0x390/0x608
tasklet_action_common.isra.13+0x1ec/0x230
tasklet_action+0x24/0x30
efi_header_end+0x1a4/0x370
The buggy address belongs to the object at ffff00002303f000
which belongs to the cache dma-kmalloc-128 of size 128
The buggy address is located 20 bytes inside of
128-byte region [ffff00002303f000, ffff00002303f080)
The buggy address belongs to the page:
page:fffffe00006c0fc0 refcount:1 mapcount:0 mapping:ffff00093200c000 index:0x0
flags: 0xffff00000000200(slab)
raw: 0ffff00000000200 dead000000000100 dead000000000122 ffff00093200c000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00002303ef00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff00002303ef80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>ffff00002303f000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff00002303f080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff00002303f100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 1c24022667 ("crypto: caam - add crypto_engine support for AEAD algorithms")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 5ed1e8b887)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
For skcipher algorithms, the input, output HW S/G tables
look like this: [IV, src][dst, IV]
Now, we can have 2 conditions here:
- there is no IV;
- src and dst are equal (in-place encryption) and scattered
and the error is an "off-by-one" in the HW S/G table.
This issue was seen with KASAN:
BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018
Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321
CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted
5.6.0-rc1-00165-ge4ef8383-dirty #4
Hardware name: LS1046A RDB Board (DT)
Call trace:
dump_backtrace+0x0/0x260
show_stack+0x14/0x20
dump_stack+0xe8/0x144
print_address_description.isra.11+0x64/0x348
__kasan_report+0x11c/0x230
kasan_report+0xc/0x18
__asan_load4+0x90/0xb0
skcipher_edesc_alloc+0x95c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Allocated by task 321:
save_stack+0x24/0xb0
__kasan_kmalloc.isra.10+0xc4/0xe0
kasan_kmalloc+0xc/0x18
__kmalloc+0x178/0x2b8
skcipher_edesc_alloc+0x21c/0x1018
skcipher_encrypt+0x84/0x150
crypto_skcipher_encrypt+0x50/0x68
test_skcipher_vec_cfg+0x4d4/0xc10
test_skcipher_vec+0x178/0x1d8
alg_test_skcipher+0xec/0x230
alg_test.part.44+0x114/0x4a0
alg_test+0x1c/0x60
cryptomgr_test+0x34/0x58
kthread+0x1b8/0x1c0
ret_from_fork+0x10/0x18
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff000022a02800
which belongs to the cache dma-kmalloc-512 of size 512
The buggy address is located 344 bytes inside of
512-byte region [ffff000022a02800, ffff000022a02a00)
The buggy address belongs to the page:
page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400
index:0x0 compound_mapcount: 0
flags: 0xffff00000010200(slab|head)
raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc
^
ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Fixes: 334d37c9e2 ("crypto: caam - update IV using HW support")
Cc: <stable@vger.kernel.org> # v5.3+
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 55b3209acb)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Configuring both caam/jr and snvs/secvio drivers as modules:
CONFIG_CRYPTO_DEV_FSL_CAAM_JR=m
CONFIG_CRYPTO_DEV_FSL_CAAM_SECVIO=m
fails with:
drivers/crypto/caam/secvio.o: In function `snvs_secvio_driver_init':
drivers/crypto/caam/secvio.c:339: multiple definition of `init_module'
drivers/crypto/caam/jr.o:drivers/crypto/caam/jr.c:854: first defined here
drivers/crypto/caam/secvio.o: In function `snvs_secvio_install_handler':
drivers/crypto/caam/secvio.c:137: multiple definition of `cleanup_module'
drivers/crypto/caam/jr.o:drivers/crypto/caam/jr.c:71: first defined here
scripts/Makefile.build:439: recipe for target 'drivers/crypto/caam/caam_jr.o' failed
make[3]: *** [drivers/crypto/caam/caam_jr.o] Error 1
This is due to trying to link two platform drivers in the same
"composite" object.
Since in fact snvs/secvio driver does not depend on caam/jr
(and should not depend on the other caam drivers in general [*]),
and to keep the fix small [**], avoid linking snvs/secvio with caam/jr.
[*] Currently the only dependency is related to I/O accessors (regs.h)
and endianness detection (ctrl.c).
From this perspective, it's important for caam controller driver
(ctrl.c) to probe before snvs/secvio driver.
[**] The proper solution would be splitting snvs/secvio from caam
(drivers, DT bindings etc.), since snvs is just a "companion module"
of caam.
Fixes: f50dd756a0 ("MLKU-38-3 crypto: caam - add SNVS / SECVIO support")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
In commit 4d370a1036 ("crypto: caam - change return code in caam_jr_enqueue function"),
the return code of caam_jr_enqueue function was changed
from 0 to -EINPROGRESS, in case of success, -ENOSPC in case
the CAAM is busy (has no space left in job ring queue),
-EIO if it cannot map the caller's descriptor.
Update the case for exiting from sm_key_job based on
the new return code from caam_jr_enqueue function.
Fixes: 4d370a1036 ("crypto: caam - change return code in caam_jr_enqueue function")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Add crypto_engine support for HASH algorithms, to make use of
the engine queue.
The requests, with backlog flag, will be listed into crypto-engine
queue and processed by CAAM when free.
Only the backlog request are sent to crypto-engine since the others
can be handled by CAAM, if free, especially since JR has up to 1024
entries (more than the 10 entries from crypto-engine).
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 21b014f038)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Add crypto_engine support for RSA algorithms, to make use of
the engine queue.
The requests, with backlog flag, will be listed into crypto-engine
queue and processed by CAAM when free. In case the queue is empty,
the request is directly sent to CAAM.
Only the backlog request are sent to crypto-engine since the others
can be handled by CAAM, if free, especially since JR has up to 1024
entries (more than the 10 entries from crypto-engine).
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit bf53795025)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Add crypto_engine support for AEAD algorithms, to make use of
the engine queue.
The requests, with backlog flag, will be listed into crypto-engine
queue and processed by CAAM when free.
If sending just the backlog request to crypto-engine, and non-blocking
directly to CAAM, the latter requests have a better chance to be
executed since JR has up to 1024 entries, more than the 10 entries
from crypto-engine.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 1c24022667)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Integrate crypto_engine into CAAM, to make use of the engine queue.
Add support for SKCIPHER algorithms.
This is intended to be used for CAAM backlogging support.
The requests, with backlog flag (e.g. from dm-crypt) will be listed
into crypto-engine queue and processed by CAAM when free.
This changes the return codes for enqueuing a request:
-EINPROGRESS if OK, -EBUSY if request is backlogged (via
crypto-engine), -ENOSPC if the queue is full, -EIO if it
cannot map the caller's descriptor.
The requests, with backlog flag, will be listed into crypto-engine
queue and processed by CAAM when free. Only the backlog request are
sent to crypto-engine since the others can be handled by CAAM, if free,
especially since JR has up to 1024 entries (more than the 10 entries
from crypto-engine).
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit ee38767f15)
Fixed conflicts with commit acbef33 ("LF-292-2 crypto: caam - add power management")
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Based on commit 6b80ea389a ("crypto: change transient busy return code to -ENOSPC"),
change the return code of caam_jr_enqueue function to -EINPROGRESS, in
case of success, -ENOSPC in case the CAAM is busy (has no space left
in job ring queue), -EIO if it cannot map the caller's descriptor.
Update, also, the cases for resource-freeing for each algorithm type.
This is done for later use, on backlogging support in CAAM.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 4d370a1036)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Create a common rsa_priv_f_done function, which based
on private key form calls the specific unmap function.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit d53e44fe98)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Changed parameters for ahash_edesc_alloc function:
- remove flags since they can be computed in
ahash_edesc_alloc, the only place they are needed;
- use ahash_request instead of caam_hash_ctx, to be
able to compute gfp flags.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 2ba1e79831)
Fixed conflicts with commit 46b49ab ("crypto: caam - remove double buffering for ahash")
which is upstream, but not in linux_imx/imx_5.4.y
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Create two common ahash_done_* functions with the dma
direction as parameter. Then, these 2 are called with
the proper direction for unmap.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit c3f7394eb9)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Create a common crypt function for each skcipher/aead/gcm/chachapoly
algorithms and call it for encrypt/decrypt with the specific boolean -
true for encrypt and false for decrypt.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit b7f17fe281)
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
HW generates a Data Size error for chacha20 requests that are not
a multiple of 64B, since algorithm state (AS) does not have
the FINAL bit set.
Since updating req->iv (for chaining) is not required,
modify skcipher descriptors to set the FINAL bit for chacha20.
[Note that for skcipher decryption we know that ctx1_iv_off is 0,
which allows for an optimization by not checking algorithm type,
since append_dec_op1() sets FINAL bit for all algorithms except AES.]
Also drop the descriptor operations that save the IV.
However, in order to keep code logic simple, things like
S/G tables generation etc. are not touched.
Fixes: 334d37c9e2 ("crypto: caam - update IV using HW support")
Signed-off-by: Horia Geant? <horia.geanta@nxp.com>
Reviewed-by: Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com>
Tested-by: Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com>
(cherry picked from commit bb1ae9dad06bdd7f0572eb50886e8b03d51a7d6c)
Add support for suspend and resume operation for PM in CAAM driver.
When the CAAM goes in suspend, the hardware is considered to do nothing.
On some platforms, the power of the CAAM is not turned off so it keeps
its configuration.
On other platforms, it doesn't so it is necessary to save the state of
the CAAM:
- JRs MID
- Address of input and output rings
Limitation:
When the CAAM is powered OFF, it is resetted so the JDKEK and TDKEK
changes. This impacts crypto transforms using MDHA split-keys
which are kept over suspend as they are encrypted with the JDKEK:
- hmac(*) from caamhash.c
- authenc(hmac(*),*) from caamalg.c
- echainiv(authenc(hmac(*),*)) from caamalg.c
The issue was already present in current code so this patch does not
add a regression in this regard.
Reviewed-by: Horia Geant? <horia.geanta@nxp.com>
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
(cherry picked from commit c151af80cfda82eae533a80fb2bb0158dffe556d)
Differences vs. i.MX BSP:
-RNG re-initialization done in ctrl, not in jr
The fix for MLK-22518 (drivers: crypto: caam: jr: Allow quiesce when quiesced)
is integrated in this patch.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
RNG (re-)initialization will be needed on pm resume path,
thus refactor the corresponding code out of the probe callback.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Valentin Ciocoi Radulescu <valentin.ciocoi@nxp.com>
The caam controller driver claims the ownership of the
whole caam register space due to which while binding the
Job Ring to fsl-jr-uio driver, it returns IOSOURCE_BUSY
error.
This patch replaces devm_request_mem_region() API with
platform_get_resource() to avoid this issue.
Fixes: eb5e94d462 ("crypto: caam - use devres to unmap memory")
Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Acked-by: Horia Geantă <horia.geanta@nxp.com>
In caam_jr_enqueue, under heavy DDR load, smp_wmb() or dma_wmb()
fail to make the input ring be updated before the CAAM starts
reading it. So, CAAM will process, again, an old descriptor address
and will put it in the output ring. This will make caam_jr_dequeue()
to fail, since this old descriptor is not in the software ring.
To fix this, use wmb() which works on the full system instead of
inner/outer shareable domains.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Add support for the crypto engine used in i.mx8mp (i.MX 8M "Plus"),
which is very similar to the one used in i.mx8mq, i.mx8mm, i.mx8mn.
[
NOTE:
Upstream support for i.MX8MN:
https://patchwork.kernel.org/patch/11319997/
partially includes this (imx_soc_table updates).
]
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
clk_prepare_enable() needs to be called earlier,
before accessing snvs registers.
While here, add a name for the CAAM SNVS clock - "ipg".
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Update caam/qi to work with QBMan from NXP SDK.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Squashed "crypto: caam/qi - fix FD congestion weight" fix.
Solved rebase conflicts:
drivers/crypto/caam/qi.c:579
kept call to dev_err_ratelimited, but changed to fd->status
drivers/crypto/caam/sg_sw_qm.h:96
kept changes from patch, but changed sg_count to len
Signed-off-by: Vlad Pelin <vlad.pelin@nxp.com>
Acked-by: Horia Geanta <horia.geanta@nxp.com>
Commit 77debf316c44 ("LFV-26 crypto: caam - fix Secure Memory driver init")
addressed SM driver initialization and also update SM test.
However, the fix for SM test is insufficient.
There are cases when SM test runs before SM driver, causing a crash
due to uninitialized "priv" pointer being dereferenced.
The fix consists in the following:
1. Since SM test is a "bare" device driver (doesn't sit on any bus),
there is no deferred probing support.
Thus we have no choice (*) but to abort SM tests with a notification.
(*) We don't want to force SM driver running first by means of
init levels etc. Just KISS.
2. SM test driver forced to being built only as a module
Since SM test driver's only goal is to run SM tests, it doesn't make
any sense to be built-in.
Building the driver as a module allows for running the tests
several times if needed (multiple modprobe & rmmod cycles).
Note: from the perspective of wanting to test repetitively, it would
make sense to force module unloading by returning an error code
in the module_init function.
However, this might affect test scripts (due to error code and/or
message output by unsuccessful module loading), so we postpone
this change for now.
Fixes: d02fe599d7d5 ("MLKU-25-3 crypto: caam - add Secure Memory support")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Acked-by: Leonard Crestez <leonard.crestez@nxp.com>
Andrey Zhizhikin