core: driver: add common i.MX MU driver

Add a common MU driver for i.MX platforms. This MU driver is used to
communicate with external security controllers.

This driver includes a generic part and

core: driver: add common i.MX MU driver

Add a common MU driver for i.MX platforms. This MU driver is used to
communicate with external security controllers.

This driver includes a generic part and an hardware abstraction layer
for low level MU functions.

The MU driver implements the HAL for the following platforms:
- mx8ulpevk
- mx8qmmek/imx8qxpmek

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

show more ...

plat: rcar: fix core pos calculation for H3 boards

Due to mistake, cluster position wasn't shifted left if chip is not
M3W. This led to erroneous core ID calculation on chips that are not
M3W. Actua

plat: rcar: fix core pos calculation for H3 boards

Due to mistake, cluster position wasn't shifted left if chip is not
M3W. This led to erroneous core ID calculation on chips that are not
M3W. Actually, this affected only H3, as only this chip has two
clusters.

Fix this by always shifting x1 (cluster ID) to the left, before doing
one additional shift for non-M3W chips.

Fixes: 572afdce53ea ("plat: rcar: Derive core map from PRR")

Reported-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Tested-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> (R-Car M3)
Tested-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com> (R-Car H3)
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

drivers: imx-i2c: add support for imx8mn

Add i2c support for imx8mn platforms

Signed-off-by: Gerard Koskamp <gerard.koskamp@nedap.com>
Reviewed-by: Robert Krikke <robert.krikke@nedap.com>
Acked-by:

drivers: imx-i2c: add support for imx8mn

Add i2c support for imx8mn platforms

Signed-off-by: Gerard Koskamp <gerard.koskamp@nedap.com>
Reviewed-by: Robert Krikke <robert.krikke@nedap.com>
Acked-by: Jorge Ramirez-Ortiz <jorge@foundries.io>

show more ...

core: plat-ls: remove OP-TEE support for LS1021A-QDS platform

LS1021A-QDS does not support OP-TEE anymore, removing its
support.

Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Acked-by: Jer

core: plat-ls: remove OP-TEE support for LS1021A-QDS platform

LS1021A-QDS does not support OP-TEE anymore, removing its
support.

Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

core: plat-ls: remove OP-TEE support for LS1021A-TWR platform

LS1021A-TWR does not support OP-TEE anymore, removing its
support.
Since LS1021A-TWR was default platform for LS, updating default
platf

core: plat-ls: remove OP-TEE support for LS1021A-TWR platform

LS1021A-TWR does not support OP-TEE anymore, removing its
support.
Since LS1021A-TWR was default platform for LS, updating default
platform also to LS1012A-RDB

Signed-off-by: Sahil Malhotra <sahil.malhotra@nxp.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

crypto_api: acipher: correct ECC NIST-P521 key size

NIST P521 uses 521-bit private keys.

This change might impact platforms that expect a certain alignment
on the key size (i.e. CAAM)

Signed-off-b

crypto_api: acipher: correct ECC NIST-P521 key size

NIST P521 uses 521-bit private keys.

This change might impact platforms that expect a certain alignment
on the key size (i.e. CAAM)

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

show more ...

drivers: caam: ecc: key size must be a multiple of 8

Enforce the alignment required by the CAAM hardware.

Notice that the NIST-P521 curve uses a 521 bit private key
hence why this change is needed.

drivers: caam: ecc: key size must be a multiple of 8

Enforce the alignment required by the CAAM hardware.

Notice that the NIST-P521 curve uses a 521 bit private key
hence why this change is needed.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Clement Faure <clement.faure@nxp.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-stm32mp1: fix use of pointer after free

Fix the following with gcc12:

| In file included from lib/libutils/isoc/include/assert.h:9,
| from core/include/drivers/serial.h:8,
|

plat-stm32mp1: fix use of pointer after free

Fix the following with gcc12:

| In file included from lib/libutils/isoc/include/assert.h:9,
| from core/include/drivers/serial.h:8,
| from core/include/drivers/stm32_uart.h:10,
| from core/arch/arm/plat-stm32mp1/main.c:14:
| core/arch/arm/plat-stm32mp1/main.c: In function 'init_console_from_dt':
| core/arch/arm/plat-stm32mp1/main.c:141:50: error: pointer 'pd' used after 'free' [-Werror=use-after-free]
| 141 | IMSG("DTB enables console (%ssecure)", pd->secure ? "" : "non-");
| | ~~^~~~~~~~
| lib/libutils/ext/include/trace.h:41:22: note: in definition of macro 'trace_printf_helper'
| 41 | __VA_ARGS__)
| | ^~~~~~~~~~~
| core/arch/arm/plat-stm32mp1/main.c:141:9: note: in expansion of macro 'IMSG'
| 141 | IMSG("DTB enables console (%ssecure)", pd->secure ? "" : "non-");
| | ^~~~
| core/arch/arm/plat-stm32mp1/main.c:139:9: note: call to 'free' here
| 139 | free(pd);
| | ^~~~~~~~

Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

drivers: imx: dcp: fix compilation address error

hwkey->data will never be null because it is an array

struct tee_hw_unique_key {
uint8_t data[HW_UNIQUE_KEY_LENGTH];
};

Fix the following w

drivers: imx: dcp: fix compilation address error

hwkey->data will never be null because it is an array

struct tee_hw_unique_key {
uint8_t data[HW_UNIQUE_KEY_LENGTH];
};

Fix the following with gcc12:

| core/drivers/imx/dcp/dcp_huk.c: In function 'tee_otp_get_hw_unique_key':
| core/drivers/imx/dcp/dcp_huk.c:71:23: error: the comparison will always evaluate as 'true' for the address of 'data' will never be NULL [-Werror=address]
| 71 | if (!hwkey || !hwkey->data) {
| | ^

Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Clement Faure <clement.faure@nxp.com>

show more ...

crypto-api: rsassa: pass algorithm to implementation

This is required for drivers that might only support some of the
algorithms.

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

crypto-api: rsassa: pass algorithm to implementation

This is required for drivers that might only support some of the
algorithms.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Clement Faure <clement.faure@nxp.com>

show more ...

drivers: zynqmp_huk: Add AES eFuse and HUK seed support

When AES eFuse is used to encrypt boot loaders and bitstreams then PUF
functionality is not available for use. When AES eFuse based encryption

drivers: zynqmp_huk: Add AES eFuse and HUK seed support

When AES eFuse is used to encrypt boot loaders and bitstreams then PUF
functionality is not available for use. When AES eFuse based encryption is
in use AES eFuse key becomes device key instead of PUF generated key.

In order to re-plenish additional device specific entropy that PUF would
provide utilize selected set of User programmable eFuses.

Selected user eFuses should be programmed during device manufacturing with
cryptographically good random numbers.

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

show more ...

drivers: zymqmp_pm: add USER eFuse support

Adds necessary defines for accessing USER eFuses.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Acked-by: Etienne Carriere <etienne.car

drivers: zymqmp_pm: add USER eFuse support

Adds necessary defines for accessing USER eFuses.

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

show more ...

drivers: zynqmp_pm: Add eFuse programming support

Add support to program eFuses utiling functionality found in PMU firmware.

If eFuse programming functionality has been disabled in PMU firmware the

drivers: zynqmp_pm: Add eFuse programming support

Add support to program eFuses utiling functionality found in PMU firmware.

If eFuse programming functionality has been disabled in PMU firmware then
programming will fail.

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

show more ...

drivers: zynqmp_pm: fix cache alignment for eFuse operation

Allocate cache aligned temporary memory for both eFuse operation request
and data buffer to make sure that operation is always cache align

drivers: zynqmp_pm: fix cache alignment for eFuse operation

Allocate cache aligned temporary memory for both eFuse operation request
and data buffer to make sure that operation is always cache aligned and to
make usage easier.

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

show more ...

core, ldelf: link: add --no-warn-execstack

When building for arm32 with GNU binutils 2.39, the linker outputs
warnings when generating some TEE core binaries (all_obj.o, init.o,
unpaged.o and tee.el

core, ldelf: link: add --no-warn-execstack

When building for arm32 with GNU binutils 2.39, the linker outputs
warnings when generating some TEE core binaries (all_obj.o, init.o,
unpaged.o and tee.elf) as well as ldelf.elf:

arm-poky-linux-gnueabi-ld.bfd: warning: atomic_a32.o: missing .note.GNU-stack section implies executable stack
arm-poky-linux-gnueabi-ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

The permissions used when mapping the TEE core stacks do not depend on
any metadata found in the ELF file. Similarly when the TEE core loads
ldelf it already creates a non-executable stack regardless of ELF
information. Therefore we can safely ignore the warnings. This is done
by adding the '--no-warn-execstack' option.

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

show more ...

core: stack check: fix debug message

The lower limit for thread stacks printed by print_stack_limits()
when CFG_CORE_DEBUG_CHECK_STACKS=y is incorrect. It needs to be
increased by STACK_CHECK_EXTRA

core: stack check: fix debug message

The lower limit for thread stacks printed by print_stack_limits()
when CFG_CORE_DEBUG_CHECK_STACKS=y is incorrect. It needs to be
increased by STACK_CHECK_EXTRA to be consistent with the value
returned by get_stack_soft_limits(). While we're at it, improve
the SP out of range message to make it EMSG() rather than DMSG() and
show the stack limits. This makes it easier to identify in which
stack the pointer was supposed to be.

Here is an example of a stack overflow panic in thread 0:

D/TC:? 0 ldelf_syscall_open_bin:142 Lookup user TA ELF cb3e5ba0-adf1-11e0-998b-0002a5d5c51b (Secure Storage TA)
E/TC:? 0 Stack pointer out of range! 0x7e7bd618 not in [0x7e7bd630 .. 0x7e7bf030]
D/TC:? 0 print_stack_limits:179 tmp [0] 0x7e7c1c90..0x7e7c24b0
D/TC:? 0 print_stack_limits:179 tmp [1] 0x7e7c2ad0..0x7e7c32f0
D/TC:? 0 print_stack_limits:179 tmp [2] 0x7e7c3910..0x7e7c4130
D/TC:? 0 print_stack_limits:179 tmp [3] 0x7e7c4750..0x7e7c4f70
D/TC:? 0 print_stack_limits:184 abt [0] 0x7e7b8710..0x7e7b9330
D/TC:? 0 print_stack_limits:184 abt [1] 0x7e7b9950..0x7e7ba570
D/TC:? 0 print_stack_limits:184 abt [2] 0x7e7bab90..0x7e7bb7b0
D/TC:? 0 print_stack_limits:184 abt [3] 0x7e7bbdd0..0x7e7bc9f0
D/TC:? 0 print_stack_limits:189 thr [0] 0x7e7bd630..0x7e7bf030
D/TC:? 0 print_stack_limits:189 thr [1] 0x7e7bfc70..0x7e7c1670
E/TC:1 0 Panic at core/kernel/thread.c:207 <check_stack_limits>
E/TC:1 0 TEE load address @ 0x7e6e5000
E/TC:1 0 Call stack:
E/TC:1 0 0x7e6f1b10 print_kernel_stack at optee_os/core/arch/arm/kernel/unwind_arm64.c:80
E/TC:1 0 0x7e7071b8 __do_panic at optee_os/core/kernel/panic.c:24
E/TC:1 0 0x7e70cd14 check_stack_limits at optee_os/core/kernel/thread.c:207
E/TC:1 0 0x7e70dcd8 __cyg_profile_func_enter at optee_os/core/kernel/thread.c:237
E/TC:1 0 0x7e766b74 memset at optee_os/lib/libutils/isoc/newlib/memset.c:76
E/TC:1 0 0x7e768928 memzero_explicit at optee_os/lib/libutils/ext/memzero_explicit.c:22
E/TC:1 0 0x7e74de54 zeromem at optee_os/core/lib/libtomcrypt/src/misc/zeromem.c:26 (discriminator 2)
E/TC:1 0 0x7e74ddd8 burn_stack at optee_os/core/lib/libtomcrypt/src/misc/burn_stack.c:24
E/TC:1 0 0x7e74a32c rijndael_ecb_encrypt at optee_os/core/lib/libtomcrypt/src/ciphers/aes/aes.c:454
E/TC:1 0 0x7e743e44 crypto_aes_enc_block at optee_os/core/lib/libtomcrypt/aes.c:45 (discriminator 2)
E/TC:1 0 0x7e6fa1d0 decrypt_block at optee_os/core/crypto/aes-gcm-sw.c:98
E/TC:1 0 0x7e6fa2ec decrypt_pl at optee_os/core/crypto/aes-gcm-sw.c:118 (discriminator 3)
E/TC:1 0 0x7e6fa400 internal_aes_gcm_update_payload_blocks at optee_os/core/crypto/aes-gcm-sw.c:143
E/TC:1 0 0x7e6f93f4 __gcm_update_payload at optee_os/core/crypto/aes-gcm.c:246
E/TC:1 0 0x7e6f9504 operation_final at optee_os/core/crypto/aes-gcm.c:273
E/TC:1 0 0x7e6f9780 __gcm_dec_final at optee_os/core/crypto/aes-gcm.c:328
E/TC:1 0 0x7e6f9840 internal_aes_gcm_dec_final at optee_os/core/crypto/aes-gcm.c:342
E/TC:1 0 0x7e6f9a64 aes_gcm_dec_final at optee_os/core/crypto/aes-gcm.c:500
E/TC:1 0 0x7e6f85cc crypto_authenc_dec_final at optee_os/core/crypto/crypto.c:427
E/TC:1 0 0x7e7352d8 authenc_decrypt_final at optee_os/core/tee/fs_htree.c:511
E/TC:1 0 0x7e736094 tee_fs_htree_read_block at optee_os/core/tee/fs_htree.c:899
E/TC:1 0 0x7e732234 ree_fs_read_primitive at optee_os/core/tee/tee_ree_fs.c:340
E/TC:1 0 0x7e7334e8 read_dent at optee_os/core/tee/fs_dirfile.c:103
E/TC:1 0 0x7e734024 tee_fs_dirfile_open at optee_os/core/tee/fs_dirfile.c:143
E/TC:1 0 0x7e731ab4 open_dirh at optee_os/core/tee/tee_ree_fs.c:552
E/TC:1 0 0x7e731b50 get_dirh at optee_os/core/tee/tee_ree_fs.c:573
E/TC:1 0 0x7e732e38 ree_fs_open at optee_os/core/tee/tee_ree_fs.c:626
E/TC:1 0 0x7e72ec60 tadb_open at optee_os/core/tee/tadb.c:227
E/TC:1 0 0x7e72f3a0 tee_tadb_open at optee_os/core/tee/tadb.c:246 (discriminator 1)
E/TC:1 0 0x7e72ff7c tee_tadb_ta_open at optee_os/core/tee/tadb.c:643
E/TC:1 0 0x7e70fed8 secstor_ta_open at optee_os/core/kernel/secstor_ta.c:19
E/TC:1 0 0x7e706648 ldelf_syscall_open_bin at optee_os/core/kernel/ldelf_syscalls.c:145
E/TC:1 0 0x7e6f54c0 tee_svc_do_call at optee_os/core/arch/arm/tee/arch_svc_a64.S:140
E/TC:1 0 0x7e6ec780 thread_svc_handler at optee_os/core/arch/arm/kernel/thread.c:1104 (discriminator 4)
E/TC:1 0 0x7e6ea35c el0_svc at optee_os/core/arch/arm/kernel/thread_a64.S:825

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

show more ...

core: fix handling of CFG_STACK_THREAD_EXTRA and CFG_STACK_TMP_EXTRA

CFG_STACK_THREAD_EXTRA and CFG_STACK_TMP_EXTRA should be included in
STACK_THREAD_SIZE and STACK_TMP_SIZE, respectively, because

core: fix handling of CFG_STACK_THREAD_EXTRA and CFG_STACK_TMP_EXTRA

CFG_STACK_THREAD_EXTRA and CFG_STACK_TMP_EXTRA should be included in
STACK_THREAD_SIZE and STACK_TMP_SIZE, respectively, because not doing so
creates inconsistencies where some places use e.g., (STACK_THREAD_SIZE +
CFG_STACK_THREAD_EXTRA) while others use STACK_THREAD_SIZE only. Note
for example the discrepancy between the stack declaration:

DECLARE_STACK(stack_thread, CFG_NUM_THREADS,
STACK_THREAD_SIZE + CFG_STACK_THREAD_EXTRA, static);

...and the thread_stack_start() function:

vaddr_t thread_stack_start(void)
{
/* ... */

return thr->stack_va_end - STACK_THREAD_SIZE;
}

With this change, the _EXTRA values should also be properly taken into
account when pager is enabled, which was not the case before.

Fixes: cca7b5ebeb9b ("core: configuration switches to tune stack sizes")
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Tested-by: Jorge Ramirez-Ortiz <jorge@foundries.io> (STM32MP1, SE050, pager)

show more ...

imx: dcp: switch to new alloc_cache_aligned()

Use commonized outer cache line aligned memory allocator instead of having
local implementation.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@va

imx: dcp: switch to new alloc_cache_aligned()

Use commonized outer cache line aligned memory allocator instead of having
local implementation.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: add allocator for cache aligned memory

Provides new common maximum cache line aligned allocator for allocating
memory to be used when communicating with different peripherals within the
CPU.

core: add allocator for cache aligned memory

Provides new common maximum cache line aligned allocator for allocating
memory to be used when communicating with different peripherals within the
CPU.

Allocated memory can be readily used with cache maintenance operations.

This is based on core/drivers/imx/dcp/dcp_utils.c.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: sort includes in tee_misc.c

Sort includes to keep it clean.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

arm: cache_helpers.h: Add cache_get_max_line_size()

Add helper for querying outer cache line size in bytes.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Jens Wiklan

arm: cache_helpers.h: Add cache_get_max_line_size()

Add helper for querying outer cache line size in bytes.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

arm.mk: Added CFG_MAX_CACHE_LINE_SHIFT for maximum cache line size

When sharing memory between CPU and peripherals it is important that data
is accurate for all parties.

Today's CPU's has multiple

arm.mk: Added CFG_MAX_CACHE_LINE_SHIFT for maximum cache line size

When sharing memory between CPU and peripherals it is important that data
is accurate for all parties.

Today's CPU's has multiple levels for caches and their sizes are platform
specific. As there is no auto detectable way to determine cache line size
during runtime so it must be defined during compilation time.

Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-k3: Add high DDR memory region

K3 devices support more than 2GB of DRAM, the extra is placed at a highmem
address of 0x880000000. If memory from this area is passed to OP-TEE
one will get the f

plat-k3: Add high DDR memory region

K3 devices support more than 2GB of DRAM, the extra is placed at a highmem
address of 0x880000000. If memory from this area is passed to OP-TEE
one will get the following error:

E/TC:1 0 std_entry_with_parg:235 Bad arg address 0x881585000

Add the highmem area to fix this.

Fixes: dfd994436ac3 ("plat-k3: Add DDR setup in k3 platform")
Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

plat-k3: Enable ARMv8 Crypto Extensions support by default

All of the currently supported K3 platforms support ARM CE, enable this
by default so it does not have to be enabled in the build command.

plat-k3: Enable ARMv8 Crypto Extensions support by default

All of the currently supported K3 platforms support ARM CE, enable this
by default so it does not have to be enabled in the build command.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

plat-k3: drivers: Reverse RNG disabling logic

We want to be able to disable SA2UL from the command line and only be
able to enable it for supported platforms. Right now we force it on
for supported

plat-k3: drivers: Reverse RNG disabling logic

We want to be able to disable SA2UL from the command line and only be
able to enable it for supported platforms. Right now we force it on
for supported platforms and allow it to be enabled still on unsupported
ones. Reverse this.

Signed-off-by: Andrew Davis <afd@ti.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...