libutee: add coverity note to TEE_Panic()

Coverity scans emits false positive "Dereference after null check"
errors because it doesn't understand that TEE_Panic() doesn't return.
Fix this by adding

libutee: add coverity note to TEE_Panic()

Coverity scans emits false positive "Dereference after null check"
errors because it doesn't understand that TEE_Panic() doesn't return.
Fix this by adding a __coverity_panic__() at the end of the function.

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

show more ...

core: mobj: fix memory leak

dynamic shared memory is not being released leading to an out of
memory condition.

Issue triggered during tests exporting the cryptographic random
generator to the REE (

core: mobj: fix memory leak

dynamic shared memory is not being released leading to an out of
memory condition.

Issue triggered during tests exporting the cryptographic random
generator to the REE (Linux) and then reading the value via the device
interface (/dev/hwrng).

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

show more ...

ta: pkcs11: private key can also be public

Even thou normal operations should mark private key a private with
CKA_PRIVATE attribute it is possible that someone could do
unexpected choise.

Specifica

ta: pkcs11: private key can also be public

Even thou normal operations should mark private key a private with
CKA_PRIVATE attribute it is possible that someone could do
unexpected choise.

Specification does not state that private key class itself means that it
is private, specification only states that CKA_PRIVATE is in control of
the privacy of the object.

This commit moves object class CKO_PRIVATE_KEY processing to normal
handling of CKA_PRIVATE.

CKA_PRIVATE is specified in:
PKCS #11 Cryptographic Token Interface Base Specification Version 2.40
Plus Errata 01
4.4 Storage Objects

Possibility of having private key object with CKA_PRIVATE as false:
PKCS #11 Cryptographic Token Interface Base Specification Version 2.40
Plus Errata 01
4.9 Private key objects

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Reviewed-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

drivers: caam: fix allocated buffer size

When a buffer is allocated for output CAAM operations,
the output buffer cache is invalidated beforehand.

To avoid data loss, an allocated buffer size shoul

drivers: caam: fix allocated buffer size

When a buffer is allocated for output CAAM operations,
the output buffer cache is invalidated beforehand.

To avoid data loss, an allocated buffer size should be a
multiple data cacheline size.

Fixes: b22795b ("drivers: caam: make use of generic memalign() implementation")
Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

drivers: caam: use dcache_get_line_size()

Remove CAAM function to get the data cache line size and
use the generic function.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Jens W

drivers: caam: use dcache_get_line_size()

Remove CAAM function to get the data cache line size and
use the generic function.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-ls: add i2c driver for NXP LS Platforms

I2C Driver compilation is enabled by default for LX2160A-RDB
and LX2160A-QDS.

Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Reviewed-by: Jens W

plat-ls: add i2c driver for NXP LS Platforms

I2C Driver compilation is enabled by default for LX2160A-RDB
and LX2160A-QDS.

Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Clement Faure <clement.faure@nxp.com>

show more ...

ta: pkcs11: Correct the return type of functions and typos

Correct return types of few functions and few typos.

Reviewed-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Etienne C

ta: pkcs11: Correct the return type of functions and typos

Correct return types of few functions and few typos.

Reviewed-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>

show more ...

ta: pkcs11: Add key size check for AES type of key

For AES Keys, the allowed lengths are 16, 24 or 32 bytes.
Return error if the key length passed when creating keys
is not one of these.

If not che

ta: pkcs11: Add key size check for AES type of key

For AES Keys, the allowed lengths are 16, 24 or 32 bytes.
Return error if the key length passed when creating keys
is not one of these.

If not checked when creating keys, error
CKR_MECHANISM_INVALID is returned later when trying
to use invalid keys which is ambiguous.The right approach
is to disallow creation of such keys.

Reviewed-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>

show more ...

ta: pkcs11: Fix interpretation of CKA_VALUE_LEN for Generic Secrets

PKCS#11 specification [1] section 2.6.3 states that - For
CKM_GENERIC_SECRET_KEY_GEN mechanism, the ulMinKeySize and
ulMaxKeySize

ta: pkcs11: Fix interpretation of CKA_VALUE_LEN for Generic Secrets

PKCS#11 specification [1] section 2.6.3 states that - For
CKM_GENERIC_SECRET_KEY_GEN mechanism, the ulMinKeySize and
ulMaxKeySize fields of the CK_MECHANISM_INFO structure
specify the supported range of key sizes, in bits.

Based on this, assumption was being made in the code that key length
specified by CKA_VALUE_LEN for keys of type CKK_GENERIC_SECRET is also
in bits. This assumption is not correct as per Section 2.6.2 in [1].
Special handling in code for CKK_GENERIC_SECRET for handling keysize
in bits has been now removed.

[1] - PKCS #11 Cryptographic Token Interface Current Mechanisms
Specification Version 2.40

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>

show more ...

ta: pkcs11: Close file handle after object has been created

When creating a object file handle was left open. This was observed in
tee-supplicant as open file handles.

This fixes the situation so t

ta: pkcs11: Close file handle after object has been created

When creating a object file handle was left open. This was observed in
tee-supplicant as open file handles.

This fixes the situation so that file handles are not left open.

Reviewed-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

build: core: add missing dependencies when generating assembly constants

The header file <generated/asm-defines.h> is created at build time. It
contains macro definitions for various offsets in C st

build: core: add missing dependencies when generating assembly constants

The header file <generated/asm-defines.h> is created at build time. It
contains macro definitions for various offsets in C structures and is
especially useful for use from assembler code. It is generated from
asm-defines.c, which includes a number of header files, of which two
are also generated at build time: <generated/arm32_sysreg.h> and
<generated/arm32_gicv3_sysreg.h>.

These dependencies are expressed nowhere in the makefiles and therefore
build errors can result. For example:

$ make out/arm-plat-vexpress/core/include/generated/.asm-defines.s
CHK out/arm-plat-vexpress/conf.mk
UPD out/arm-plat-vexpress/conf.mk
CHK out/arm-plat-vexpress/include/generated/conf.h
UPD out/arm-plat-vexpress/include/generated/conf.h
CC out/arm-plat-vexpress/core/include/generated/.asm-defines.s
In file included from core/arch/arm/include/arm.h:99,
from core/arch/arm/include/kernel/thread.h:12,
from core/arch/arm/kernel/asm-defines.c:8:
core/arch/arm/include/arm32.h:167:10: fatal error: generated/arm32_sysreg.h: No such file or directory
167 | #include <generated/arm32_sysreg.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

The error in [1] is believed to have the same root cause: during
parallel build the generated header file might have been created by one
job but not yet written to when another job would open it. The compiler
would see an empty file, thus the missing declarations.

Add the missing dependencies via a new variable at the location where
asm-defines.c is added to the build.

Note that the other core .c files depending on these generated sysreg
headers are not affected because their .o files explicitly depend on
FORCE-GENSRCcore (which generates the headers).

Link: [1] https://ci.linaro.org/job/ledge-oe-premerge-ci/182/DISTRO=rpb,MACHINE=ledge-ti-am572x,label=docker-buster-amd64/console
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat: rcar: Obtain memory layout from DT

Since the ATF is passing a DT fragment to OpTee-OS, parse the memory
information from this DT fragment. This makes it possible to run the
OpTee-OS on any mem

plat: rcar: Obtain memory layout from DT

Since the ATF is passing a DT fragment to OpTee-OS, parse the memory
information from this DT fragment. This makes it possible to run the
OpTee-OS on any memory layout instead of the few hard-coded options.
Switch the default platform to this DT based approach, but retain the
legacy platforms as well for backward compatibility.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

show more ...

plat: rcar: Derive core map from PRR

Instead of hard-coding the core count and the core ID mapping,
derive this information from the PRR register. All R-Car3 SoCs
have either one or two 4-core CPU c

plat: rcar: Derive core map from PRR

Instead of hard-coding the core count and the core ID mapping,
derive this information from the PRR register. All R-Car3 SoCs
have either one or two 4-core CPU clusters composed of CA53 or
CA57, except for M3W/M3W+, which has two CA57s and four CA53s.

So the approach here is to always set core count to 8, read out
PRR register once on boot, and then calculate the core ID using
CorePos = CoreId + (ClusterId << (IsM3W ? 1 : 0))

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>

show more ...

core: libmbedtls: CMAC: remove code duplication

Use common code for AES CMAC and 3DES CMAC

Signed-off-by: Alexander Zakharov <uglym8@gmail.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

core: libmbedtls: CMAC: remove code duplication

Use common code for AES CMAC and 3DES CMAC

Signed-off-by: Alexander Zakharov <uglym8@gmail.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

ta: pkcs11: Add implementation for random number generation

Add code for handling C_SeedRandom() and C_GenerateRandom() functionality.

Reviewed-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed

ta: pkcs11: Add implementation for random number generation

Add code for handling C_SeedRandom() and C_GenerateRandom() functionality.

Reviewed-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

ta: pkcs11: Allocate command ID for random number generation

Allocate command IDs for C_SeedRandom() and C_GenerateRandom()
functionality.

Reviewed-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Revi

ta: pkcs11: Allocate command ID for random number generation

Allocate command IDs for C_SeedRandom() and C_GenerateRandom()
functionality.

Reviewed-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>

show more ...

shippable: se050: Foundries Plug-and-Trust 0.0.2 update

Pickup the quaterly release of the Plug-and-Trust library.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Jerome Foriss

shippable: se050: Foundries Plug-and-Trust 0.0.2 update

Pickup the quaterly release of the Plug-and-Trust library.

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

show more ...

crypto: se050: Foundries Plug-and-Trust Release 0.0.2

The Foundries Plug-and-Trust library tracks NXP Plug-and-Trust
quaterly releases.

Modifications in the NXP library sources require a new prepro

crypto: se050: Foundries Plug-and-Trust Release 0.0.2

The Foundries Plug-and-Trust library tracks NXP Plug-and-Trust
quaterly releases.

Modifications in the NXP library sources require a new preprocessor
macro to be defined.

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

show more ...

drivers: crypto: se050: improve maintainability

Replace explicit c-flags duplication across makefiles with single
shared definition.

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

drivers: crypto: se050: improve maintainability

Replace explicit c-flags duplication across makefiles with single
shared definition.

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

show more ...

shippable: extract Plug-and-Trust library to unversioned directory

The Plug and Trust library archive creates a directory when extracted
that contains the version number. This is fine in general but

shippable: extract Plug-and-Trust library to unversioned directory

The Plug and Trust library archive creates a directory when extracted
that contains the version number. This is fine in general but is
detrimental to our CI script, because the version number needs to
appear 7 times in the script, which is error-prone when upgrading.

Change the extraction command to create /root/se050 instead of
/root/se050-0.0.1, etc. This way the Plug and Trust version number is
only present in the package URL.

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

show more ...

core: mobj: fixup undefined mobj_mapped_shm_alloc

Provide a function definition when CFG_CORE_DYN_SHM is not configured.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Jens Wi

core: mobj: fixup undefined mobj_mapped_shm_alloc

Provide a function definition when CFG_CORE_DYN_SHM is not configured.

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

show more ...

virt: round down TA RAM memory size to page size

It is possible that get_ta_ram_size() would return size which is not
aligned to a small page size. This will cause panic in core_init_mmu_prtn()
func

virt: round down TA RAM memory size to page size

It is possible that get_ta_ram_size() would return size which is not
aligned to a small page size. This will cause panic in core_init_mmu_prtn()
function.

To fix this we need to round down calculated value to a page size.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

drivers: caam: make use of generic memalign() implementation

Make use of the newly implemented memalign() function for the CAAM
driver.
Remove the previous CAAM memalign() implementation and its ass

drivers: caam: make use of generic memalign() implementation

Make use of the newly implemented memalign() function for the CAAM
driver.
Remove the previous CAAM memalign() implementation and its associated
debugging structures.

Signed-off-by: Clement Faure <clement.faure@nxp.com>
Acked-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

Add 3DES CMAC implementation

CMAC is a Cipher-Based MAC that improves some of the security deficiencies
found in CBC-MAC. It is described in NIST SP800-38B as a mode of operation
for approved symmet

Add 3DES CMAC implementation

CMAC is a Cipher-Based MAC that improves some of the security deficiencies
found in CBC-MAC. It is described in NIST SP800-38B as a mode of operation
for approved symmetric block chipers, namely AES and TDEA.

CMAC has similar use cases and security guarantees as HMAC, with the
difference that it uses a different primitive (symmetric cipher instead
of hash function).
CMAC may be appropriate for information systems in which an approved block
cipher is more readily available than an approved hash function.

Commonly it is used for symmetric key diversification (ASC X9 TR 31-2018),
data integrity assurance (ICV).

CMAC is public domain.

OP-TEE core already supports for AES CMAC, but not TDEA CMAC. This commit
adds TDEA CMAC support.

Signed-off-by: Alexander Zakharov <uglym8@gmail.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
[jf: wrap commit description at 75 characters]
Signed-off-by: Jerome Forissier <jerome@forissier.org>

show more ...

core: libtomcrypt: add 3DES CMAC implementation

Add 3DES CMAC (NIST SP800-38B).

Signed-off-by: Alexander Zakharov <uglym8@gmail.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Acked-by: E

core: libtomcrypt: add 3DES CMAC implementation

Add 3DES CMAC (NIST SP800-38B).

Signed-off-by: Alexander Zakharov <uglym8@gmail.com>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
[jf: add commit description]
Signed-off-by: Jerome Forissier <jerome@forissier.org>

show more ...