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: pass TEE_ATTR_RSA_OAEP_MGF_HASH to RSA-OAEP implementations

OP-TEE currently doesn't support using a different hash for MGF1
with RSA-OAEP. However, this is required for AOSP compatibility
(e.

core: pass TEE_ATTR_RSA_OAEP_MGF_HASH to RSA-OAEP implementations

OP-TEE currently doesn't support using a different hash for MGF1
with RSA-OAEP. However, this is required for AOSP compatibility
(e.g. in EncryptionOperationsTest.RsaOaepWithMGFDigestSuccess [1]).

Pass the MGF1 attribute to crypto implementations. Note that
only libtomcrypt supports this feature at the moment, so other
implementations will either fail or fall back to libtomcrypt when
passed a different MGF1 hash.

Link: https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/main/security/keymint/aidl/vts/functional/KeyMintTest.cpp#5552 [1]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto_bignum_free(): add indirection and set pointer to NULL

To prevent human mistake, crypto_bignum_free() sets the location of the
bignum pointer to NULL after freeing it.

Signed-off-by: J

core: crypto_bignum_free(): add indirection and set pointer to NULL

To prevent human mistake, crypto_bignum_free() sets the location of the
bignum pointer to NULL after freeing it.

Signed-off-by: Jihwan Park <jihwp@amazon.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@foss.st.com>

show more ...

crypto: versal: ecc: allow software fallback on key allocation

The driver only supports ECDH/ECDSA key types. Other key types shall be
entirely handled by a software implementation enabled at compil

crypto: versal: ecc: allow software fallback on key allocation

The driver only supports ECDH/ECDSA key types. Other key types shall be
entirely handled by a software implementation enabled at compile time.

Fixes xtest regression 4006:
regression_4006.43 Asym Crypto case 426 algo 0x80000046 line 373

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

crypto_api: acipher: ecc key allocation API, pass the key type

For Elliptic Curve, the cryptographic API can fallback to its software
operation instead of failing due to the lack of hardware support

crypto_api: acipher: ecc key allocation API, pass the key type

For Elliptic Curve, the cryptographic API can fallback to its software
operation instead of failing due to the lack of hardware support.

The relevant code can be see seen in the function
crypto_acipher_alloc_ecc_keypair(..).

crypto_api/acipher/ecc.c however does not pass the key type to the
relevant driver and therefore the backend driver can not take the
correct action at allocation time.

This commit addresses that limitation.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Clement Faure <clement.faure@nxp.com>

show more ...

drivers: crypto: versal: do not use deprecated algorithm macros

The TEE_ALG_ECDSA_P384 and TEE_ALG_ECDSA_P521 constants are deprecated
since commit fe2fd3ff46c0 ("GP131: Add TEE_ALG_ECDH_DERIVE_SHAR

drivers: crypto: versal: do not use deprecated algorithm macros

The TEE_ALG_ECDSA_P384 and TEE_ALG_ECDSA_P521 constants are deprecated
since commit fe2fd3ff46c0 ("GP131: Add TEE_ALG_ECDH_DERIVE_SHARED_SECRET
and TEE_ALG_ECDSA_SHA*"). Therefore use TEE_ALG_ECDSA_SHA384 or
TEE_ALG_ECDSA_SHA512 instead (no functional change since the
aforementioned commit made them equal).

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

versal: enable the crypto driver

The crypto driver API provides an extra indirection level to enable
different ciphers.

Since Versal ACAP supports acipher and authenc, enable them.

Falling-back to

versal: enable the crypto driver

The crypto driver API provides an extra indirection level to enable
different ciphers.

Since Versal ACAP supports acipher and authenc, enable them.

Falling-back to software operations (RSA sign/verify) triggers a
fault detection; we will disable this config while a solution is
found.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

crypto: versal: rsa: only support sign/verify operations

RSA encryption/decryption is not supported (the PLM does not
return the size of the encrypted/decrypted buffers).

Signed-off-by: Jorge Ramir

crypto: versal: rsa: only support sign/verify operations

RSA encryption/decryption is not supported (the PLM does not
return the size of the encrypted/decrypted buffers).

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

crypto: versal: ecc: sign/verify fix

Both the message (hash) and the generated signatures must be swapped.

The following custom tests were executed for P384 (prime384v1) and
P521 (nistp521) curves.

crypto: versal: ecc: sign/verify fix

Both the message (hash) and the generated signatures must be swapped.

The following custom tests were executed for P384 (prime384v1) and
P521 (nistp521) curves.

Signing and verifying using pkcs#11 alone (ie like done in xtest) was
not sufficient to capture this bug.

PTOOL='pkcs11-tool --module /usr/lib/libckteec.so.0.1.0'
SO_PIN=55555555
PIN=44444444
FILE=hello

printf "OP-TEE: create key pair"
$PTOOL --id 01 --label ldts --token-label fio --pin $PIN \
--keypairgen \
--key-type EC:prime384v1

printf "OP-TEE: read the public key"
$PTOOL -l --pin $PIN --id 01 \
--read-object --type pubkey --output-file pubkey.spki

printf "Openssl: export key to PEM"
openssl ec -inform DER -outform PEM -in pubkey.spki -pubin > pubkey.pub

printf "Create file to sign"
echo "hello world" > $FILE

printf "OpenSSL: create the file sha384"
openssl dgst -binary -sha384 $FILE > $FILE.hash

printf "OP-TEE: generate signature "
$PTOOL --pin $PIN --id 01 --label ldts --token-label fio \
--sign
--input-file $FILE.hash
--output-file $FILE.sig
--mechanism ECDSA
-f openssl

printf "OpenSSL: verify signature"
openssl dgst -sha384 -verify pubkey.pub -signature "$FILE".sig "$FILE"

printf "OP-TEE: verify signature"
$PTOOL --pin $PIN --id 01 --label ldts --token-label fio \
--verify \
--input-file $FILE.hash \
--signature-format openssl \
--signature-file $FILE.sig \
--mechanism ECDSA

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

drivers: versal: SHA3-384 engine support

Enable the PLM controlled SHA3-384 cryptographic engine for TEE core
usage.

Since the engine does not have the concept of "context", it can't
provide the le

drivers: versal: SHA3-384 engine support

Enable the PLM controlled SHA3-384 cryptographic engine for TEE core
usage.

Since the engine does not have the concept of "context", it can't
provide the level support required by user-space (multiple parallel
contexts) hence why it is being provided just to the core.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Nathan Menhorn <nathan.menhorn@amd.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

crypto: versal: RSA driver

This driver uses the PLM xilsecure service to deliver RSA
encryption/decryption functionality.

https://github.com/Xilinx/embeddedsw

Signed-off-by: Jorge Ramirez-Ortiz <j

crypto: versal: RSA driver

This driver uses the PLM xilsecure service to deliver RSA
encryption/decryption functionality.

https://github.com/Xilinx/embeddedsw

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

crypto: versal: elliptic curve cryptography driver

This driver uses the PLM xilsecure service to deliver ECC sign/verify
functionality.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked

crypto: versal: elliptic curve cryptography driver

This driver uses the PLM xilsecure service to deliver ECC sign/verify
functionality.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

crypto: versal: authentication driver

This driver uses the PLM xilsecure service to deliver authentication
functionality using AES-GCM.

The driver currently does not handle unaligned data and lengt

crypto: versal: authentication driver

This driver uses the PLM xilsecure service to deliver authentication
functionality using AES-GCM.

The driver currently does not handle unaligned data and lengths; due
to this the corresponding xtest regression test will not pass
(xtest -t regression 4005 will fail).

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

crypto: versal: interprocessor communication

Interface to the PLM xilsecure service.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

crypto: versal: interprocessor communication

Interface to the PLM xilsecure service.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...