rng: rename plat_rng_init() to plat_init_soft_prng()

plat_rng_init() has a misleading name as it could be seen as a function
which initializes the hardware RNG. It's job is to seed the software RNG

rng: rename plat_rng_init() to plat_init_soft_prng()

plat_rng_init() has a misleading name as it could be seen as a function
which initializes the hardware RNG. It's job is to seed the software RNG
though, so rename it to plat_init_soft_prng() and clarify the function
description to avoid confusion.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>

show more ...

rng: only call plat_rng_init() with CFG_WITH_SOFTWARE_PRNG

OP-TEE can generate random numbers either using a hardware RNG or a
software RNG. In the latter case OP-TEE can only generate secure random

rng: only call plat_rng_init() with CFG_WITH_SOFTWARE_PRNG

OP-TEE can generate random numbers either using a hardware RNG or a
software RNG. In the latter case OP-TEE can only generate secure random
numbers when the software RNG is seeded by a hardware RNG.

Seeding the software RNG is done with plat_rng_init(). Many SoCs assume
their implementation is hardware RNG only, so they don't need seeding
the software RNG and provide an empty plat_rng_init() just because the
function is mandatory.

This has the result that if someone decides to use the software RNG on
one of these SoCs by enabling CFG_WITH_SOFTWARE_PRNG, he will end up
with an unseeded software RNG.

Prevent that by calling plat_rng_init() only when CFG_WITH_SOFTWARE_PRNG
is enabled and remove all empty plat_rng_init() implementations. That
way compiling with CFG_WITH_SOFTWARE_PRNG will result in a linker error
unless CFG_INSECURE is enabled as well, in which case the weak default
implementation is used.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>

show more ...

drivers: versal_net: trng: Add support for newer PKI TRNG and use in PKI driver

The TRNG IP Core included in Versal NET PKI Accelerator is close to Versal
PMC TRNG IP Core but includes hardware DF a

drivers: versal_net: trng: Add support for newer PKI TRNG and use in PKI driver

The TRNG IP Core included in Versal NET PKI Accelerator is close to Versal
PMC TRNG IP Core but includes hardware DF and can be called a 2nd version
of that IP Core.

Largely based on previous work by
Jeremie Corbier <jeremie.corbier@provenrun.com> and
huynhdanvo <dan.vo@provenrun.com>.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal_net: pki: Enhance status and error checking; be verbose if needed

Mapping all PKI Engine status bits to TEE_ERROR_GENERIC is not suitable in
all cases. Especially SIGNATURENOTVALID s

drivers: versal_net: pki: Enhance status and error checking; be verbose if needed

Mapping all PKI Engine status bits to TEE_ERROR_GENERIC is not suitable in
all cases. Especially SIGNATURENOTVALID shall be mapped to
TEE_ERROR_SIGNATURE_INVALID. TEE_AsymmetricVerifyDigest() requires this to
work properly.

Moreover, this commit tries to introduce reasonable reporting of errors and
unexpected values, in case something goes wrong.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal_net: pki: Fix queue alignment and DMA setup

The DMA part of the PKI Accelerator seems to support up to 4 equally sized
buffers to fetch requests and data from, and to return data to

drivers: versal_net: pki: Fix queue alignment and DMA setup

The DMA part of the PKI Accelerator seems to support up to 4 equally sized
buffers to fetch requests and data from, and to return data to
(RequestQueue). Such a buffer, also primarily called a "page", needs to be
aligned to a certain boundary which is NOT the cache line length!

Experiments showed that natural alignment does work. Thus, since the driver
uses a fixed size of 4 KiB (PKI_QUEUE_BUF_SIZE) for these "pages", we
enforce alignment to 4 KiB. It remains unknown whether smaller (but bigger
than cache line length) alignments do work or not.

Furthermore the DMA setup assumed a "page" size of 64 KiB, defined by the
very misleading symbol PKI_RQ_CFG_PAGE_SIZE_1024 with value 0x10, which
represents ln2(64KiB). In concert with this, the offset to write data back
to (5th descriptor word), also assumed the size of 64 KiB of a page. Since
only 4 KiB "pages" have been allocated in the first place, this setup is
rather dangerous, since the PKI Accelerator is under the impression that
the actual page size is bigger.
So, this commit makes the code consistent by using 4 KiB as "page" size in
all relevant places.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal_net: pki: Add driver for Versal NET PKI Accelerator

The Versal NET variant comes with a dedicated PKI engine. This driver makes
use of the engine for ECDSA P-256, P-384, and P-521 si

drivers: versal_net: pki: Add driver for Versal NET PKI Accelerator

The Versal NET variant comes with a dedicated PKI engine. This driver makes
use of the engine for ECDSA P-256, P-384, and P-521 sign, verify and key
generation operations.

Largely based on previous work by
Jeremie Corbier <jeremie.corbier@provenrun.com>.

For now, this commit omits the previous work's direct (memory-mapped) use
of one of the dedicated TRNG instances within the PKI Accelerator. Support
for it is to be added later. Instead the regular system random number
generator is used (=> crypto_rng_read()).

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal: ecc: Separate code using PLM firmware into its own file

In preparation for introducing a driver for Versal NET's PKI Accelerator
block.

Largely based on previous work by
Jeremie Co

drivers: versal: ecc: Separate code using PLM firmware into its own file

In preparation for introducing a driver for Versal NET's PKI Accelerator
block.

Largely based on previous work by
Jeremie Corbier <jeremie.corbier@provenrun.com>.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal_net: rsa: Add support for flavor-specific command RSA_PRIVATE_DECRYPT

In PLM Firmware release v2024.2 module XilSecure introduced a Versal NET
specific variant of API id 0x503 (RSA_P

drivers: versal_net: rsa: Add support for flavor-specific command RSA_PRIVATE_DECRYPT

In PLM Firmware release v2024.2 module XilSecure introduced a Versal NET
specific variant of API id 0x503 (RSA_PRIVATE_DECRYPT). In contrast to
Versal, XilSecure's XSecure_RsaInParam::KeyAddr is pointing to the
structure XSecure_RsaKeyParam instead of directly pointing to the buffer
comprising exponent and modulus. XSecure_RsaKeyParam has separate members
to point to exponent and modulus.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal_net: aes: No alignment restrictions for payload on update

Like Versal ACAP, Versal NET platform does not allow zero-length payloads
due to limitations in the XilSecure DMA driver. Ho

drivers: versal_net: aes: No alignment restrictions for payload on update

Like Versal ACAP, Versal NET platform does not allow zero-length payloads
due to limitations in the XilSecure DMA driver. However, in contrast to
Versal ACAP, there are no additional alignment rules in effect.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal: mbox: Rework

- Offer a generic IPI/Mailbox API in versal_mbox.c and ...
- ... provide the default IPI channel to the PMC for other drivers in
versal_pmc.c .

- Improve performance

drivers: versal: mbox: Rework

- Offer a generic IPI/Mailbox API in versal_mbox.c and ...
- ... provide the default IPI channel to the PMC for other drivers in
versal_pmc.c .

- Improve performance by doing notification by direct, memory-mapped
register access instead of doing it through the SecureMonitor.

Largely based on previous work by
Jeremie Corbier <jeremie.corbier@provenrun.com>.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal: mbox: Enhance buffer allocation

- Allow versal_mbox_alloc() to fail and properly handle this at all call
sites.

- Introduce versal_mbox_free() next to _alloc().

Largely based on

drivers: versal: mbox: Enhance buffer allocation

- Allow versal_mbox_alloc() to fail and properly handle this at all call
sites.

- Introduce versal_mbox_free() next to _alloc().

Largely based on previous work by
Jeremie Corbier <jeremie.corbier@provenrun.com>.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal: aes: Fix check for payload length on update

PLM Firmware does not allow zero-length payloads due to limitations in the
XilSecure DMA driver. Additionally further alignment rules are

drivers: versal: aes: Fix check for payload length on update

PLM Firmware does not allow zero-length payloads due to limitations in the
XilSecure DMA driver. Additionally further alignment rules are in effect,
depending on a regular update or a final update.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

drivers: versal: ecc: Enable support for ECC curve NIST P256

For this to work, Versal PLM Firmware needs to be compiled with
XSECURE_ECC_SUPPORT_NIST_P256 defined. Like with
XSECURE_ECC_SUPPORT_NIST

drivers: versal: ecc: Enable support for ECC curve NIST P256

For this to work, Versal PLM Firmware needs to be compiled with
XSECURE_ECC_SUPPORT_NIST_P256 defined. Like with
XSECURE_ECC_SUPPORT_NIST_P521 to support NIST P521. Note that NIST P384 is
enabled by default in PLM Firmware.

Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>

show more ...

drivers: versal: Update API ids to v2024.1 and newer PLM firmware release, only

IMPORTANT: This commit breaks compatibility with pre-v2024.1 PLM firmware
releases!

Since PLM firmware rel

drivers: versal: Update API ids to v2024.1 and newer PLM firmware release, only

IMPORTANT: This commit breaks compatibility with pre-v2024.1 PLM firmware
releases!

Since PLM firmware release v2022.1 there have been multiple changes to the
PLM firmware, specifically the XilSecure API ids and a new KAT subsystem
API id. Since release v2024.1 the API id situation did not change anymore -
at least up to v2025.1.

In addition to the above changes, the following breaking changes regarding
RSA and PUF support should be highlighted here:

In PLM firmware release v2022.2 module XilSecure has been updated to pack
the RSA public exponent right after the modulus rather than at a fixed 512
bytes (RSA 4096 key size) offset. See PLM firmware commit [1] for v2022.2
and [2] for later versions.

Also in PLM firmware release v2022.2 [3], module XilPuf removed the 1st
member RegMode from structure XPuf_DataAddr and made 4k syndrome mode the
only support one.

Largely based on previous work by
Jeremie Corbier <jeremie.corbier@provenrun.com>.

Link: https://github.com/Xilinx/embeddedsw/commit/c2dd2ebac38e [1]
Link: https://github.com/Xilinx/embeddedsw/commit/5cd79b2891dc [2]
Link: https://github.com/Xilinx/embeddedsw/commit/943aa4479aad [3]
Signed-off-by: Joachim Foerster <joachim.foerster@missinglinkelectronics.com>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Tested-by: Nathan Menhorn <nathan.menhorn@amd.com>
Reviewed-by: Sean McGinn <sean.mcginn@amd.com>
Reviewed-by: Lucas Kiker <lucas.kiker@amd.com>
Reviewed-by: Sindhu Raveendra <Sindhu.Raveendra@amd.com>
Reviewed-by: Clemens Nasenberg <clemens.nasenberg@amd.com>
Reviewed-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

show more ...

core: crypto_api: fix underflow in emsa_pkcs1_v1_5_encode()

Guard against an integer underflow in emsa_pkcs1_v1_5_encode() that can
occur when calculating the padding field in the EMA-PKCS1-v1_5 enc

core: crypto_api: fix underflow in emsa_pkcs1_v1_5_encode()

Guard against an integer underflow in emsa_pkcs1_v1_5_encode() that can
occur when calculating the padding field in the EMA-PKCS1-v1_5 encoding.

Fixes: f5a70e3efb80 ("drivers: crypto: generic resources for crypto device driver - RSA")
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

show more ...

crypto: asu: send hash address in request buffer for digest

Update driver to read digest from hash address sent to firmware
instead of response buffer

Fixes: 74ddb42edbe0 ("crypto: asu: Add crypto

crypto: asu: send hash address in request buffer for digest

Update driver to read digest from hash address sent to firmware
instead of response buffer

Fixes: 74ddb42edbe0 ("crypto: asu: Add crypto hash driver")
Signed-off-by: Harish Ediga <harish.ediga@amd.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

crypto: asu: fix command header length and race condition

- Updated asu_create_header() to pass command length in words
(sizeof(*cp)/sizeof(uint32_t)) instead of zero, to align with
ASUFW requir

crypto: asu: fix command header length and race condition

- Updated asu_create_header() to pass command length in words
(sizeof(*cp)/sizeof(uint32_t)) instead of zero, to align with
ASUFW requirements for proper command parsing.
- Multiple crypto drivers can submit request to shared buffer.
Make sure all queue parameters are update in spin_lock.

Fixes: 7f2d4e10736f ("drivers: amd: Add ASU support")
Signed-off-by: Harish Ediga <harish.ediga@amd.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

drivers: crypto: hisilicon: fix qp memory leak

Fix the null pointer access issue for hisilicon QM driver.

Fixes: c7f9abcee87f ("drivers: implement HiSilicon Queue Management (QM) module")
Signed-of

drivers: crypto: hisilicon: fix qp memory leak

Fix the null pointer access issue for hisilicon QM driver.

Fixes: c7f9abcee87f ("drivers: implement HiSilicon Queue Management (QM) module")
Signed-off-by: zhaozheng7 <zhaozheng96@outlook.com>
Acked-by: Zexi Yu <yuzexi@hisilicon.com>

show more ...

crypto: asu: Add crypto hash driver

Add support for following Hash algorithms
SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512

Signed-off-by: Harsh Jain <h.jain@amd.com>
Signed-off-by: Aksha

crypto: asu: Add crypto hash driver

Add support for following Hash algorithms
SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512

Signed-off-by: Harsh Jain <h.jain@amd.com>
Signed-off-by: Akshay Belsare <akshay.belsare@amd.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

drivers: caam: fix cache invalidation of RSA buffer

When using CAAM to generate an RSA key the CPU caching of the DMA
buffers need to be controlled to ensure the correct visibility for both
devices.

drivers: caam: fix cache invalidation of RSA buffer

When using CAAM to generate an RSA key the CPU caching of the DMA
buffers need to be controlled to ensure the correct visibility for both
devices. For the n parameter the wrong address was used when
invalidating the CPU cache after the DMA operation, resulting in <key
length> bytes of the stack being invalidated (without flushing to
memory) instead of the buffer.

The first potential consequence of this is that any parts of the n
buffer that were cached during the key generation won't get read from
RAM, resulting in a corrupt key. This is unlikely since the n buffer
was correctly flushed immediately before starting the CAAM operation.
To reliably reproduce this, a read that should normally be harmless can
be inserted immediately before caam_jr_enqueue:
((volatile uint8_t *)genkey.n.data)[0];

The second effect of this bug is that parts of the do_gen_keypair stack
frame will have its cache lines invalidated (again without write back to
memory). With 4096 bit keys and a compiler that produces the right stack
layout this affects callee saved registers, the return pointer and
potentially a stack canary. I have not been able to see the effects of
this on my iMX8MQ test device.

Fixes: ccbcceeb73c1 ("drivers: caam: add CAAM key support for RSA")
Signed-off-by: Martin Nyhus <martin@nyhus.dev>
Acked-by: Sahil Malhotra <sahil.malhotra@nxp.com>

show more ...

drivers: caam: handle serialization of short params

Adjusts the caam key serialization code to account for keys where
sec_size < buf.length. When that is the case the serialization can only
touch th

drivers: caam: handle serialization of short params

Adjusts the caam key serialization code to account for keys where
sec_size < buf.length. When that is the case the serialization can only
touch the first sec_size bytes since the rest are invalid, and the
serialized length is thus sec_size.

If the default key type has been changed to plain this can happen during
RSA keygen if the d parameter ends up shorter than the key size in
bytes. In that case the valid bytes are at the front of the buffer and
do_gen_keypair accounts for this by setting sec_size correctly, and
caam_key_serialize_to_bn is called with an inkey in the sec_size <
buf.length state. This ended up creating corrupt keys for roughly 1% of
keygens, and was caught by various RSA tests in optee_test.

Fixes: 1495f6c4a82a ("drivers: caam: add CAAM key driver")
Signed-off-by: Martin Nyhus <martin@nyhus.dev>
Acked-by: Sahil Malhotra <sahil.malhotra@nxp.com>

show more ...

drivers: caam: fix bits/bytes confusion

Fixes two mixups of bits and bytes in caam_key_init that roughly cancel
each other out. Both sec_size and the result from
caam_key_serialized_size are values

drivers: caam: fix bits/bytes confusion

Fixes two mixups of bits and bytes in caam_key_init that roughly cancel
each other out. Both sec_size and the result from
caam_key_serialized_size are values in bytes, so the key sizes in bits
need to be converted. For plain text keys this makes no difference to
the result since they cancel each other out exactly.

For the default key type of BLACK_CCM the blob overhead is now correctly
counted as bytes instead of bits which decreases the headroom, but since
the default config of 4576 was calculated correctly, the assert still
shouldn't fail.

Fixes: 1495f6c4a82a ("drivers: caam: add CAAM key driver")
Signed-off-by: Martin Nyhus <martin@nyhus.dev>
Acked-by: Sahil Malhotra <sahil.malhotra@nxp.com>

show more ...

driver: crypto: hisilicon: fix qm timeout variable type

The type of the timeout variable is fixed to prevent overflow

Signed-off-by: Zexi Yu <yuzexi@hisilicon.com>
Acked-by: Jens Wiklander <jens.wi

driver: crypto: hisilicon: fix qm timeout variable type

The type of the timeout variable is fixed to prevent overflow

Signed-off-by: Zexi Yu <yuzexi@hisilicon.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

driver: crypto: hisilicon: fix CKEY_LEN macro value

Fix CKEY_LEN macro value for hisilicon SEC driver

Fixes: 562874beda99 ("drivers: crypto: hisilicon: Add cipher algorithm")
Signed-off-by: Zexi Yu

driver: crypto: hisilicon: fix CKEY_LEN macro value

Fix CKEY_LEN macro value for hisilicon SEC driver

Fixes: 562874beda99 ("drivers: crypto: hisilicon: Add cipher algorithm")
Signed-off-by: Zexi Yu <yuzexi@hisilicon.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

drivers: crypto: fix SM2 ECC encrypt and decrypt

Adds checks that the destination buffer has room for the result in
ecc_sm2_decrypt() and ecc_sm2_encrypt(). Note that these two functions
not reachab

drivers: crypto: fix SM2 ECC encrypt and decrypt

Adds checks that the destination buffer has room for the result in
ecc_sm2_decrypt() and ecc_sm2_encrypt(). Note that these two functions
not reachable upstream since none of the crypto drivers registers ECC
encrypt or decrypt drivers. So fix this before it becomes a problem.

Fixes: f4f85ac774af ("drivers: crypto: add SM2 ECC encrypt and decrypt")
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Zexi Yu <yuzexi@hisilicon.com>

show more ...