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 ...

arm32: libutils, libutee, ta: add .note.GNU-stack section to .S files

When building for arm32 with GNU binutils 2.39, the linker outputs
warnings when linking Trusted Applications:

arm-unknown-lin

arm32: libutils, libutee, ta: add .note.GNU-stack section to .S files

When building for arm32 with GNU binutils 2.39, the linker outputs
warnings when linking Trusted Applications:

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

We could silence the warning by adding the '--no-warn-execstack' option
to the TA link flags, like we did in the parent commit for the TEE core
and ldelf. Indeed, ldelf always allocates a non-executable piece of
memory for the TA to use as a stack.

However it seems preferable to comply with the common ELF practices in
this case. A better fix is therefore to add the missing .note.GNU-stack
sections in the assembler files.

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

libutee: add SHA3 algorithm identifiers

Add SHA3 algorithm identifiers from TEE Internal Core API Specification
Public Release v1.3.1.

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

libutee: add SHA3 algorithm identifiers

Add SHA3 algorithm identifiers from TEE Internal Core API Specification
Public Release v1.3.1.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Jerome Forissier <jerome.forissier@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 ...

plat-k3: drivers: ti-sci: Do not print error when message not acknowledged

When the system controller firmware denies a request, we are informed
of this by the lack of an acknowledge flag in the res

plat-k3: drivers: ti-sci: Do not print error when message not acknowledged

When the system controller firmware denies a request, we are informed
of this by the lack of an acknowledge flag in the response. This is
not always an error in cases when we are only testing for permissions.
Do not print error messages in this path. The TI-SCI API caller will
still print the appropriate message if needed.

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

show more ...

plat-k3: drivers: Set SA2UL firewall region addresses

This firewall region is normally already set to cover our RNG, but that
is not guaranteed. To ensure we actually protect the RNG with this regio

plat-k3: drivers: Set SA2UL firewall region addresses

This firewall region is normally already set to cover our RNG, but that
is not guaranteed. To ensure we actually protect the RNG with this region,
explicitly set the address here to the RNG start and end addresses.

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

show more ...

libutils: util.h: add get_field_u{32,64}() and set_field_u{32,64}()

This commit defines macros for getting and setting bit fields.

Signed-off-by: Marouene Boubakri <marouene.boubakri@nxp.com>
Revie

libutils: util.h: add get_field_u{32,64}() and set_field_u{32,64}()

This commit defines macros for getting and setting bit fields.

Signed-off-by: Marouene Boubakri <marouene.boubakri@nxp.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

clang.mk: fix build on AArch64 host

When building on an AArch64 host and using OP-TEE's build.git [1], the
AArch64 cross compiler prefix is "aarch64-linux-" instead of the usual
"aarch64-linux-gnu-"

clang.mk: fix build on AArch64 host

When building on an AArch64 host and using OP-TEE's build.git [1], the
AArch64 cross compiler prefix is "aarch64-linux-" instead of the usual
"aarch64-linux-gnu-". This happens due to [2]. Clang still expects
--target=aarch64-linux-gnu so for convenience map the prefix accordingly
in mk/clang.mk.

Link: [1] https://github.com/OP-TEE/build.git
Link: [2] https://github.com/OP-TEE/build/blob/3.18.0/toolchain.mk#L97
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...