Add initial UniPhier platform support

This introduces support for Socionext UniPhier SoCs. This support
includes LD11 and LD20 SoCs only. Tested with Akebi96 board[1].

[1] https://www.96boards.org/

Add initial UniPhier platform support

This introduces support for Socionext UniPhier SoCs. This support
includes LD11 and LD20 SoCs only. Tested with Akebi96 board[1].

[1] https://www.96boards.org/product/akebi96/

Signed-off-by: Tetsuya Yoshizaki <yoshizaki.tetsuya@socionext.com>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: mmu: remove TEE/TA RAM from total RAM

On platforms where the DT is parsed from the device tree, devices can
pass in the complete available memory. This is in accordance with the
device tree sp

core: mmu: remove TEE/TA RAM from total RAM

On platforms where the DT is parsed from the device tree, devices can
pass in the complete available memory. This is in accordance with the
device tree specification which mandates that the total physical memory
should be passed in the memory nodes.
Remove the TA and TEE RAM from the passed in memory, reserved-memory
nodes are used to indicate that part of the RAM is not accessible to
Linux. Fixes the following warning on some i.MX platforms:

I/TC: Non-secure external DT found
E/TC:0 0 check_phys_mem_is_outside:330 Non-sec mem (0x10000000:0x40000000) overlaps map (type 2 0x4e000000:0x5d000)
E/TC:0 0 Panic at core/arch/arm/mm/core_mmu.c:334 <check_phys_mem_is_outside>
E/TC:0 0 TEE load address @ 0x4e000000
E/TC:0 0 Call stack:
E/TC:0 0 0x4e006fd1

Fixes https://github.com/OP-TEE/optee_os/issues/3567
Fixes https://github.com/OP-TEE/optee_os/issues/3710

Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: arm: mm: fix VA overflow issue in assign_mem_va()

Fix assign_mem_va() that is missing VA limit check on 64bit machines.
This change catches the overflow at address assignation preventing TEE
t

core: arm: mm: fix VA overflow issue in assign_mem_va()

Fix assign_mem_va() that is missing VA limit check on 64bit machines.
This change catches the overflow at address assignation preventing TEE
to panic in a not obvious way when the out of bound address is accessed.

Signed-off-by: Khoa Hoang <admin@khoahoang.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-stm32mp1: SCMI service for platform shared clocks

Add support for clocks in stm32mp1 SCMI server. This allows the secure
world to expose clock services for clock non-secure world is allowed to

plat-stm32mp1: SCMI service for platform shared clocks

Add support for clocks in stm32mp1 SCMI server. This allows the secure
world to expose clock services for clock non-secure world is allowed to
access (state, rate) but that can only be effectively accessed from
secure world due to the TZ secure hardening of the SoC.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-stm32mp1: SCMI service for non-secure reset controllers

Embed a SCMI server in stm32mp1 to handle SCMI reset domain requests
from the non-secure world for resource that, because of secure
harde

plat-stm32mp1: SCMI service for non-secure reset controllers

Embed a SCMI server in stm32mp1 to handle SCMI reset domain requests
from the non-secure world for resource that, because of secure
hardening of the system, are restricted to secure world accesses only.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-stm32mp1: foundation for SCMI service

Embed a SCMI server in stm32mp1 based on SCMI message drivers.
The platform currently supports only the SCMI Base protocol.

Platform provides 2 Arm SMCCC

plat-stm32mp1: foundation for SCMI service

Embed a SCMI server in stm32mp1 based on SCMI message drivers.
The platform currently supports only the SCMI Base protocol.

Platform provides 2 Arm SMCCC fastcall communication channels each
using a small shared memory buffer is SYSRAM manage with a SMT header
for SCMI message exchange.

Default disable CFG_CORE_ASLR, CFG_LOCKDEP, CFG_TEE_CORE_DEBUG and
CFG_UNWIND for TEE RAM memory constraints since SCMI server with a
fastcall message processing path consumes several pages of SoC internal
SYSRAM where TEE pager resides.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>

show more ...

plat-stm32mp1: remove useless macros in SMC SiP handler

Remove unused macros in stm32mp1 platform SMC SiP handler source file.

Fixes: d9c569c9c765 ("plat-stm32mp1: prepare for SiP SMC services")
Si

plat-stm32mp1: remove useless macros in SMC SiP handler

Remove unused macros in stm32mp1 platform SMC SiP handler source file.

Fixes: d9c569c9c765 ("plat-stm32mp1: prepare for SiP SMC services")
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat: rcar: Print SREC when generating the SREC file

Print SREC when generating the SREC file instead of GEN, which is
likely copied from neighboring entry in the same Makefile.

Signed-off-by: Mare

plat: rcar: Print SREC when generating the SREC file

Print SREC when generating the SREC file instead of GEN, which is
likely copied from neighboring entry in the same Makefile.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-stm32mp1: prepare for SiP SMC services

Implement secure monitor platform handlers foundations for
platform stm32mp1 to handle SiP SMC services.

Signed-off-by: Etienne Carriere <etienne.carrier

plat-stm32mp1: prepare for SiP SMC services

Implement secure monitor platform handlers foundations for
platform stm32mp1 to handle SiP SMC services.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

plat-stm32mp1: assign last 4kB of sysram as shared memory

Allow the last 4kByte of stm32mp1 SYSRAM internal RAM to be
assigned to non-secure world when used as SCMI shared memory.
ETZPC memory firew

plat-stm32mp1: assign last 4kB of sysram as shared memory

Allow the last 4kByte of stm32mp1 SYSRAM internal RAM to be
assigned to non-secure world when used as SCMI shared memory.
ETZPC memory firewall is configured accordingly from service
late initialization level as ETPCZ driver is initialized from
service init level when embedded BTD support is enabled.

Platform configuration switches CFG_STM32MP1_SCMI_SHM_BASE and
CFG_STM32MP1_SCMI_SHM_SIZE are used to define the SCMI shared
memory location.

Compilation asserts that if CFG_TZSRAM_START is define inside SYSRAM
then it fully resides inside the secure SYSRAM area as per SoC ETZPC
implementation that mandates the non-secure SYSRAM to be above (higher
address) the secure SYSRAM.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-stm32mp1: clock: secure and non-secure gateable clocks

Array stm32mp1_clk_gate[] defines the clock resources. This change
adds an attribute to the clocks in stm32mp1_clk_gate array. Clocks
unde

plat-stm32mp1: clock: secure and non-secure gateable clocks

Array stm32mp1_clk_gate[] defines the clock resources. This change
adds an attribute to the clocks in stm32mp1_clk_gate array. Clocks
under RCC[TZEN] hardening are tagged SEC and clocks always assigned
to non-secure world as per SoC implementation are tagged N_S.

Non-secure clocks that OP-TEE expects to enable are enabled without
increase of their reference counter and, for consistency, are never
disabled by TEE Core. Note that such clocks may be accessed by
OP-TEE Core when the non-secure world is not executing, for example
at boot time or could be when system is suspending/resuming.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-stm32mp1: shared resources: remove unused stm32mp_clock_is_*()

Remove unused functions stm32mp_clock_is_shareable(),
stm32mp_clock_is_shared() and stm32mp_clock_is_non_secure()? These
were init

plat-stm32mp1: shared resources: remove unused stm32mp_clock_is_*()

Remove unused functions stm32mp_clock_is_shareable(),
stm32mp_clock_is_shared() and stm32mp_clock_is_non_secure()? These
were initially designed to allow a secure service to expose clocks
to non-secure world. These functions are now deprecated since
stm32mp_nsec_can_access_clock() was introduced.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

plat-stm32mp1: shared resources: helper for shareable clocks

stm32mp_nsec_can_access_clock() reports whether a clock is assigned
to the secure world only or if it can be manipulated by the non-secur

plat-stm32mp1: shared resources: helper for shareable clocks

stm32mp_nsec_can_access_clock() reports whether a clock is assigned
to the secure world only or if it can be manipulated by the non-secure
world through some service exposed by secure world as a SCMI server.

Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

core: optimize AArch64 AES-GCM routines

Optimize handling of the last odd AES-GCM block by reusing function
recently added to boost AArch32 performance. Resulting in a small gain
in performance and

core: optimize AArch64 AES-GCM routines

Optimize handling of the last odd AES-GCM block by reusing function
recently added to boost AArch32 performance. Resulting in a small gain
in performance and fewer lines of code.

With this patch together with the recent changes the throughput of
AArch64 AES-GCM has increased from around 400MiB/s to 470MiB/s with
blocks of 4096 bytes.

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

show more ...

core: optimize AArch32 AES-GCM routines

In AArch32 there are not enough SIMD registers to make a fused GHASH and
AES-CTR assembly function. But we can do better than using the default
implementation

core: optimize AArch32 AES-GCM routines

In AArch32 there are not enough SIMD registers to make a fused GHASH and
AES-CTR assembly function. But we can do better than using the default
implementation. By carefully using the GHASH and AES primitive assembly
functions there's some gain in performance.

Before this patch throughput was around 12MiB/s to now a bit more than
110MiB/s with blocks of 4096 bytes.

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

show more ...

core: add ce_aes_xor_block()

Adds ce_aes_xor_block() which xors two memory blocks of size
TEE_AES_BLOCK_SIZE and saves the result back into memory. The operations
are done with SIMD instructions so

core: add ce_aes_xor_block()

Adds ce_aes_xor_block() which xors two memory blocks of size
TEE_AES_BLOCK_SIZE and saves the result back into memory. The operations
are done with SIMD instructions so the memory blocks may be unaligned,
but VFP must be enabled with thread_kernel_enable_vfp().

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

show more ...

core: crypto: remove internal_aes_gcm_expand_enc_key()

Removes internal_aes_gcm_expand_enc_key() which is replaced by
crypto_aes_expand_enc_key().

Reviewed-by: Etienne Carriere <etienne.carriere@li

core: crypto: remove internal_aes_gcm_expand_enc_key()

Removes internal_aes_gcm_expand_enc_key() which is replaced by
crypto_aes_expand_enc_key().

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: update AArch64 GHASH acceleration routines

Update AArch64 GHASH acceleration routines for improved performance.

The core parts of assembly and wrapper updates are written by
Ard Biesheuvel <a

core: update AArch64 GHASH acceleration routines

Update AArch64 GHASH acceleration routines for improved performance.

The core parts of assembly and wrapper updates are written by
Ard Biesheuvel <ard.biesheuvel@linaro.org>, see [1].

Link: [1] https://github.com/torvalds/linux/commit/22240df7ac6d76a271197571a7be45addef2ba15
Acked-by: Jerome Forissier <jerome@forissier.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto: remove internal_aes_gcm_encrypt_block()

Replaces calls to internal_aes_gcm_encrypt_block() with calls to
crypto_aes_enc_block(). Removes internal_aes_gcm_encrypt_block().

Reviewed-by:

core: crypto: remove internal_aes_gcm_encrypt_block()

Replaces calls to internal_aes_gcm_encrypt_block() with calls to
crypto_aes_enc_block(). Removes internal_aes_gcm_encrypt_block().

Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: crypto: unaligned aes-gcm acceleration

The Arm CE code supports working with unaligned data. In order to make
full use of that is the generic __weak function
internal_aes_gcm_update_payload_bl

core: crypto: unaligned aes-gcm acceleration

The Arm CE code supports working with unaligned data. In order to make
full use of that is the generic __weak function
internal_aes_gcm_update_payload_block_aligned() replaced with
internal_aes_gcm_update_payload_blocks(). The latter now supports
working with unaligned buffers.

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

show more ...

core: arm: pmull_ghash_update_*() accepts unaligned payload

Updates the relevant ld1 and vld1 instructions for AArch64 and AArch32
respectively to allow unaligned src and head parameters.

Reviewed-

core: arm: pmull_ghash_update_*() accepts unaligned payload

Updates the relevant ld1 and vld1 instructions for AArch64 and AArch32
respectively to allow unaligned src and head parameters.

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

show more ...

core: crypto: refactor aes-gcm implementation

Adds struct internal_ghash_key to represent the ghash key instead of
some lose fields inside struct internal_aes_gcm_state.

Software of CE configuratio

core: crypto: refactor aes-gcm implementation

Adds struct internal_ghash_key to represent the ghash key instead of
some lose fields inside struct internal_aes_gcm_state.

Software of CE configuration is done explicitly in
core/crypto/aes-gcm-sw.c, dropping the __weak attribute for all
functions but internal_aes_gcm_update_payload_block_aligned() which
is only overridden with CFG_CRYPTO_WITH_CE=y in AArch64.

Content of aes-gcm-private.h is moved into internal_aes-gcm.h.

internal_aes_gcm_gfmul() is made available for generic GF
multiplication.

The CE versions of internal_aes_gcm_expand_enc_key() and
internal_aes_gcm_encrypt_block() are now only wrappers around
crypto_accel_aes_expand_keys() and crypto_accel_aes_ecb_enc().

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

show more ...

core: add accelerated SHA-256 routines

Adds an Arm CE accelerated SHA-256 function to core/arch/arm/crypto. The
code originates from the previous implementation inside LTC library.
With this multipl

core: add accelerated SHA-256 routines

Adds an Arm CE accelerated SHA-256 function to core/arch/arm/crypto. The
code originates from the previous implementation inside LTC library.
With this multiple crypto libraries can share the function.

The old CFG_CRYPTO_SHA256_ARM64_CE and CFG_CRYPTO_SHA256_ARM32_CE are
replaced by CFG_CRYPTO_SHA256_ARM_CE.

CFG_CORE_CRYPTO_SHA256_ACCEL is introduced as to indicate that some kind of
SHA-256 acceleration is available, not necessarily based on Arm CE.

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

show more ...

core: add accelerated SHA1 routines

Adds an Arm CE accelerated SHA1 function to core/arch/arm/crypto. The code
originates from the previous implementation inside LTC library. With
this multiple cryp

core: add accelerated SHA1 routines

Adds an Arm CE accelerated SHA1 function to core/arch/arm/crypto. The code
originates from the previous implementation inside LTC library. With
this multiple crypto libraries can share the function.

The old CFG_CRYPTO_SHA1_ARM64_CE and CFG_CRYPTO_SHA1_ARM32_CE are
replaced by CFG_CRYPTO_SHA1_ARM_CE.

CFG_CORE_CRYPTO_SHA1_ACCEL is introduced as to indicate that some kind of
SHA-1 acceleration is available, not necessarily based on Arm CE.

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

show more ...

core: add accelerated AES routines

Adds Arm CE accelerated AES routines to core/arch/arm/crypto. The code
originates from the previous implementation inside LTC library. With
this multiple crypto li

core: add accelerated AES routines

Adds Arm CE accelerated AES routines to core/arch/arm/crypto. The code
originates from the previous implementation inside LTC library. With
this multiple crypto library can share these routines.

A new header file, <crypto/crypto_accel.h>, is added with primitive
functions implementing crypto accelerated ciphers.

The old CFG_CRYPTO_AES_ARM64_CE and CFG_CRYPTO_AES_ARM32_CE are
replaced by CFG_CRYPTO_AES_ARM_CE.

CFG_CORE_CRYPTO_AES_ACCEL is introduced as to indicate that some kind of
AES acceleration is available, not necessarily based on Arm CE.

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

show more ...