plat-k3: drivers: Add basic support for TI System Control Interface (TI-SCI) protocol

Texas Instruments System Control Interface (TI-SCI) Message Protocol
is used in Texas Instruments System on Chip

plat-k3: drivers: Add basic support for TI System Control Interface (TI-SCI) protocol

Texas Instruments System Control Interface (TI-SCI) Message Protocol
is used in Texas Instruments System on Chip (SoC) such as those
in keystone family K3 SoC to communicate between various compute
processors with a central system controller entity.

TISCI message protocol provides support for management of various
hardware entities within the SoC. Add support driver to allow
communication with system controller entity within the SoC using the
Secure Proxy.

Introduce the basic registration and query capability for the
driver protocol as part of this change. Subsequent patches add in
functionality specific to the TI-SCI features.

Further information can be found in TI-SCI documentation:
https://software-dl.ti.com/tisci/esd/latest/index.html

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

show more ...

plat-k3: drivers: Add secure proxy driver for communication with System Controller

Secure Proxy is a communication scheme in Texas Instrument's devices
intended to provide an unique communication pa

plat-k3: drivers: Add secure proxy driver for communication with System Controller

Secure Proxy is a communication scheme in Texas Instrument's devices
intended to provide an unique communication path from various processors
in the System on Chip(SoC) to a central System Controller.

Secure Proxy instance exposes "threads" or "proxies" which is
primary representation of "a" communication channel. Each thread is
preconfigured by System controller configuration based on SoC usage
requirements. Secure proxy by itself represents a single "queue" of
communication but allows the proxies to be independently operated.

For communication with TISCI, Secure Proxy driver is required in OP-TEE.

NOTE: Secure proxy configuration is only done by System Controller,
hence these are assumed to be pre-configured instances.

Provide the driver support for Secure Proxy and thread instances.

Tested on AM65x.

See AM65x Technical Reference Manual (SPRUID7E, April 2018)
for further details: https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf

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

show more ...

symbolize.py: translate TA panic codes

When a TA panics, the TEE core shows the panic code as follows:

E/TC:? 0 TA panicked with code 0xffff000f

The value is whatever was passed to TEE_Panic() by

symbolize.py: translate TA panic codes

When a TA panics, the TEE core shows the panic code as follows:

E/TC:? 0 TA panicked with code 0xffff000f

The value is whatever was passed to TEE_Panic() by the TA or the library
that caused the panic; typically, the TEE Intenal Core API functions
implemented in libutee. It quite often happens that this value is a
TEE_Result code. Therefore it is convenient to translate the hexadecimal
value to a symbolic name (TEE_ERROR_*). With this commit, if a match is
found, the name is shown in parentheses like so:

E/TC:? 0 TA panicked with code 0xffff000f (TEE_ERROR_SECURITY)

If the code doesn't correspond to a known TEE_Result value however
nothing is appended to the output.

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

show more ...

libutils: fix MTE error in realloc()

With memory tagging realloc() should only untag the old buffer if the
allocation of a new buffer is successful.

The implementation of realloc() prior to this pa

libutils: fix MTE error in realloc()

With memory tagging realloc() should only untag the old buffer if the
allocation of a new buffer is successful.

The implementation of realloc() prior to this patch is based on bgetr().
This is not so convenient with MTE enabled since the old buffer must be
untagged before calling bgetr(). If realloc() fails the memory tags must
be restored, but this was not done.

Restoring the tags is made somewhat more complicated by the fact that
the size reported by bget_buf_size() may actually be larger than the
size of the tagged buffer. Memalign() is sometimes forced to allocate
buffers larger than requested in order to honor the requested alignment.

So instead of using bgetr(), realloc() is implemented using bget(),
memcpy(), memset() and brel() as needed. This is the same thing that
bgetr() did, except that the old buffer is not untagged until a new
buffer has been successfully allocated.

Fixes: 08a5c4f9ae42 ("libutils: add MTE support in malloc() and friends")
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (vexpress-qemu_armv8a gp_20056)
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

ci: azure: add build for CFG_SECURE_PARTITION=y

Add config for building the S-EL1 SPMC with support for S-EL0 SPs.

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Balint Dob

ci: azure: add build for CFG_SECURE_PARTITION=y

Add config for building the S-EL1 SPMC with support for S-EL0 SPs.

Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>

show more ...

MAINTAINERS: add TI AM62x and AM64x

Adds MAINTAINER for the AM64x and AM62x SoC lines from Texas Instruments.

AM64x Technical Reference Manual: https://www.ti.com/lit/pdf/spruim2
AM62x Technical Re

MAINTAINERS: add TI AM62x and AM64x

Adds MAINTAINER for the AM64x and AM62x SoC lines from Texas Instruments.

AM64x Technical Reference Manual: https://www.ti.com/lit/pdf/spruim2
AM62x Technical Reference Manual: https://www.ti.com/lit/pdf/spruiv7

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

show more ...

ci: azure: build for k3-am62x and k3-am64x

Adds ci build for the AM64x and AM62x SoC lines from Texas Instruments.

AM64x Technical Reference Manual: https://www.ti.com/lit/pdf/spruim2
AM62x Technic

ci: azure: build for k3-am62x and k3-am64x

Adds ci build for the AM64x and AM62x SoC lines from Texas Instruments.

AM64x Technical Reference Manual: https://www.ti.com/lit/pdf/spruim2
AM62x Technical Reference Manual: https://www.ti.com/lit/pdf/spruiv7

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

show more ...

core: sp_mem: fix get_cattr() callback name

Commit 8afe7a7c5220 ("core: rename mobj_get_cattr() to
mobj_get_mem_type()") renames the get_cattr() callback in struct
mobj_ops(). However, sp_mem wasn't

core: sp_mem: fix get_cattr() callback name

Commit 8afe7a7c5220 ("core: rename mobj_get_cattr() to
mobj_get_mem_type()") renames the get_cattr() callback in struct
mobj_ops(). However, sp_mem wasn't updated as part of this change, so
currently it doesn't compile. Fix this and get aligned with the new
naming.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>

show more ...

symbolize.py: strip MTE tag

When the Armv8.5 Memory Tagging Extension is enabled, the address shown
in data-abort messages may include a non-zero tag. For example (xtest
1038):

E/TC:? 0 User mode

symbolize.py: strip MTE tag

When the Armv8.5 Memory Tagging Extension is enabled, the address shown
in data-abort messages may include a non-zero tag. For example (xtest
1038):

E/TC:? 0 User mode data-abort at address 0x2000000401824f0 (tag check fault)

The tag needs to be cleared before the address can be translated into
symbol + offset.

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

show more ...

libutils: add MTE support in malloc() and friends

Adds support for memory tagging using the hardware assisted Armv8.5-A
Memory Tagging Extension in malloc() and friends.

When allocating memory the

libutils: add MTE support in malloc() and friends

Adds support for memory tagging using the hardware assisted Armv8.5-A
Memory Tagging Extension in malloc() and friends.

When allocating memory the acquired memory range in tagged a special
pointer with the tag coded in the top bits of the pointer. Accessing
this memory without the coded tag will result in a Tag Check Exception.

MTE is enabled for both OP-TEE core and TAs at the same time with
CFG_MEMTAG=y.

When the memory is freed it's untagged again. All accesses to heap
memory using old/stale pointers will be caught. This is an efficient
method to catch use-after-free and buffer overruns on the heap. The
buffer overruns are limited in granularity to blocks of 16 bytes.
However, the heap itself is also managed in blocks of 16 bytes so
smaller buffer overruns will not damage the heap.

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

show more ...

core: syscalls: strip tags from user space pointers

Strips the tags from user space pointers before using them.
We're relying on TCR_EL1.TCMA0=1 to make the accesses unchecked.

Acked-by: Jerome For

core: syscalls: strip tags from user space pointers

Strips the tags from user space pointers before using them.
We're relying on TCR_EL1.TCMA0=1 to make the accesses unchecked.

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

show more ...

core: add support for MTE

Adds support for the Armv8.5-A Memory Tagging Extension with
CFG_MEMTAG=y.

A memtag.h API is introduced to handle this extension. If CFG_MEMTAG=n
the API doesn't add any o

core: add support for MTE

Adds support for the Armv8.5-A Memory Tagging Extension with
CFG_MEMTAG=y.

A memtag.h API is introduced to handle this extension. If CFG_MEMTAG=n
the API doesn't add any overhead and the behaviour is unchanged. With
CFG_MEMTAG=y a check is performed to see if the platform can support MTE
and the API is dynamically configured accordingly. This means that it's
safe to have CFG_MEMTAG=y even for platforms not supporting MTE. There
will be some minimal overhead then, but likely not noticeable.

An entry is also added in the TEE_PROPSET_TEE_IMPLEMENTATION for a u32
property "org.trustedfirmware.optee.cpu.feat_memtag_implemented". The
property is set to a non-zero value only if CFG_CORE_MEMTAG is
configured and the underlying CPU supports FEAT_MTE.

This commit still only uses the default tag with the value 0 resulting
in unchanged pointers when accessing memory. However, all plumbing is in
place allowing for instance tagging of the heap in a later commit.

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

show more ...

core: map TA memory using TEE_MATTR_MEM_TYPE_TAGGED

Maps TA memory using the TEE_MATTR_MEM_TYPE_TAGGED which results in
tagged cached memory if the system has it enabled.

Acked-by: Etienne Carriere

core: map TA memory using TEE_MATTR_MEM_TYPE_TAGGED

Maps TA memory using the TEE_MATTR_MEM_TYPE_TAGGED which results in
tagged cached memory if the system has it enabled.

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

show more ...

core: mm: add TEE_MATTR_MEM_TYPE_TAGGED

Adds TEE_MATTR_MEM_TYPE_TAGGED used to map tagged memory as defined in
Armv8.5-A Memory Tagging Extension (MTE).

All OP-TEE core memory should be mapped as t

core: mm: add TEE_MATTR_MEM_TYPE_TAGGED

Adds TEE_MATTR_MEM_TYPE_TAGGED used to map tagged memory as defined in
Armv8.5-A Memory Tagging Extension (MTE).

All OP-TEE core memory should be mapped as tagged memory when supported.

Memory potentially shared with non-secure world or other firmware should
not be mapped as tagged since we don't have control over the tags then.

The mappings used by TEE_MATTR_MEM_TYPE_TAGGED is replaced by
TEE_MATTR_MEM_TYPE_CACHED if MTE isn't supported or configured.

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

show more ...

libutee: arm64: add read_dczid_el0()

Adds read_dczid_el0() to read Data Cache Zero ID register.

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

libutee: arm64: add read_dczid_el0()

Adds read_dczid_el0() to read Data Cache Zero ID register.

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

show more ...

core: arm64.h: add MTE related defines

Adds defines for bits in SCTLR_EL1 TCR_EL1 and GCR_EL1 relating to the
Memory Tagging Extension (MTE).

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.

core: arm64.h: add MTE related defines

Adds defines for bits in SCTLR_EL1 TCR_EL1 and GCR_EL1 relating to the
Memory Tagging Extension (MTE).

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

show more ...

core: arm64.h: use 64-bit macros for TCR_* defines

The TCR_EL1 register is a 64-bit register, update the defines to use
64-bit macros instead to reflect that.

Reviewed-by: Jerome Forissier <jerome.

core: arm64.h: use 64-bit macros for TCR_* defines

The TCR_EL1 register is a 64-bit register, update the defines to use
64-bit macros instead to reflect that.

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

show more ...

core: arm64.h: use BIT64() for SCTLR_* defines

The SCTLR_EL1 register is a 64-bit register, update the defines to use
the BIT64() macro instead to reflect that.

Reviewed-by: Jerome Forissier <jerom

core: arm64.h: use BIT64() for SCTLR_* defines

The SCTLR_EL1 register is a 64-bit register, update the defines to use
the BIT64() macro instead to reflect that.

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

show more ...

core: arm64: add MTE bits for ID_AA64PFR1

Adds fields in register ID_AA64PFR1 to report the presence of Memory
Tagging Extension (MTE).

Adds feat_mte_implemented() to report which MTE feature flav

core: arm64: add MTE bits for ID_AA64PFR1

Adds fields in register ID_AA64PFR1 to report the presence of Memory
Tagging Extension (MTE).

Adds feat_mte_implemented() to report which MTE feature flavor is
supported.

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

show more ...

core: recognize tag check faults in abort handler

Adds support in the abort handler to recognize tag check faults.

Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carr

core: recognize tag check faults in abort handler

Adds support in the abort handler to recognize tag check faults.

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

show more ...

libutils: refactor heap tagging

Refactors the heap tagging with CFG_CORE_SANITIZE_KADDRESS to use two new
hooks maybe_tag_buf() and maybe_untag_buf().

maybe_tag_buf() is called from raw_malloc_retu

libutils: refactor heap tagging

Refactors the heap tagging with CFG_CORE_SANITIZE_KADDRESS to use two new
hooks maybe_tag_buf() and maybe_untag_buf().

maybe_tag_buf() is called from raw_malloc_return_hook() which is called
after bget(). maybe_untag_buf() is called before brel() is called.

This removes some of the local modifications to bget.c.

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

show more ...

core: rename mobj_get_cattr() to mobj_get_mem_type()

Renames mobj_get_cattr() to mobj_get_mem_type(). The mobj operation
get_ctype() is also renamed to get_mem_type().

This commit is only about ren

core: rename mobj_get_cattr() to mobj_get_mem_type()

Renames mobj_get_cattr() to mobj_get_mem_type(). The mobj operation
get_ctype() is also renamed to get_mem_type().

This commit is only about renaming ctype to mem_type, no changes in
behaviour.

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

show more ...

drivers: imx_ocotp: initialize OCOTP driver earlier

Initialize the OCOTP driver earlier with service_init() instead of
driver_init().

With CFG_CORE_HUK_SUBKEY_COMPAT=y, tee_fs_init_key_manager() an

drivers: imx_ocotp: initialize OCOTP driver earlier

Initialize the OCOTP driver earlier with service_init() instead of
driver_init().

With CFG_CORE_HUK_SUBKEY_COMPAT=y, tee_fs_init_key_manager() and
consequently tee_otp_get_die_id() get executed earlier than the
OCOTP driver initialization. tee_fs_init_key_manager() is called by
service_init_late() routine.

On platforms featuring the OCOTP driver, the function
tee_otp_get_die_id() relies on the driver to be initialized.

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

show more ...

scripts/gen_tee_bin.py: inlude .ctors in included sections

Includes the section .ctors in sections included in the pager binary.
This fixes a problem where the constructor function pointers are all

scripts/gen_tee_bin.py: inlude .ctors in included sections

Includes the section .ctors in sections included in the pager binary.
This fixes a problem where the constructor function pointers are all
zeroes. Constructors are normally not used by OP-TEE, but with
CFG_CORE_SANITIZE_KADDRESS=y it's used to initialize access to global
variables.

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

show more ...

arm: vfp_a32: check the existence of FPU NEON by CPACR

Almost all Cortex-A processors come with a Floating-Point Unit (FPU)
and most also have a NEON unit. However, use of registers D16-D31 of
the V

arm: vfp_a32: check the existence of FPU NEON by CPACR

Almost all Cortex-A processors come with a Floating-Point Unit (FPU)
and most also have a NEON unit. However, use of registers D16-D31 of
the VFP register file depends on the processor's FPU implementation.

Arm coprocessor access control register (CPACR.D32DIS) indicates if
FPU and Advanced SIMD is implemented. Check this bit to see if the
processor is supported or not.

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

show more ...