core, ldelf: add support for runtime loading of shared libraries

This commit prepares the introduction of libdl, a dynamic linking
library which will allow TAs to load shared libraries at run time,

core, ldelf: add support for runtime loading of shared libraries

This commit prepares the introduction of libdl, a dynamic linking
library which will allow TAs to load shared libraries at run time,
and resolve symbols on demand. It adds the following function to the
system PTA, inspired from the POSIX dlopen() and dlsym():

- system_dlopen(): takes a UUID and flags. Performs an upcall into
ldelf which then uses the usual system PTA functions to load an map the
requested library into the address space of the calling TA.
- system_dlsym(): takes a UUID and a symbol name. The symbol is
looked up in the library specified by UUID by calling into ldelf. If
UUID is all zeros, all the mapped binaries are searched.

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

show more ...

libutee: add tee_uuid_from_str()

Moves internal function parse_uuid() from ldelf/ta_elf.c to libutee so
that it may be used by TAs or other user-space libraries such as the
upcoming libdl. The funct

libutee: add tee_uuid_from_str()

Moves internal function parse_uuid() from ldelf/ta_elf.c to libutee so
that it may be used by TAs or other user-space libraries such as the
upcoming libdl. The function is renamed to tee_uuid_from_str() and
declared in tee_internal_api_extensions.h.

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

show more ...

ftrace: Add function execution time support

Add support to dump function execution time at corresponding function
exit points in output ftrace buffer.

To achieve proper function execution time we n

ftrace: Add function execution time support

Add support to dump function execution time at corresponding function
exit points in output ftrace buffer.

To achieve proper function execution time we need to exclude TA suspend
time from timestamps, so add corresponding support in TEE core.

Also user mapping must be active to access ftrace buffer, so do that
during TA resume.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (QEMU)
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

libutee: add headers for user-space to access sysregs

User space may require to access system registers like generic timer
registers in case function tracing is enabled etc. So provide headers
for u

libutee: add headers for user-space to access sysregs

User space may require to access system registers like generic timer
registers in case function tracing is enabled etc. So provide headers
for user space to access sysregs.

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

show more ...

ftrace: Enable support for 32 bit apps

By default 32 bit trusted applications are compiled in thumb mode but
thumb mode doesn't support function graph tracing due to missing frame
pointer support re

ftrace: Enable support for 32 bit apps

By default 32 bit trusted applications are compiled in thumb mode but
thumb mode doesn't support function graph tracing due to missing frame
pointer support required to trace function call chain. So rather compile
trusted applications in ARM mode in case function tracing is enabled.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

show more ...

core: pta_system: support memory remap

Adds PTA_SYSTEM_REMAP to support changing virtual address of an already
established mapping in a TA.

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

core: pta_system: support memory remap

Adds PTA_SYSTEM_REMAP to support changing virtual address of an already
established mapping in a TA.

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

show more ...

core: pta_system: add PTA_SYSTEM_SET_PROT

Adds PTA_SYSTEM_SET_PROT to support changing protection of already
established memory mappings.

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

core: pta_system: add PTA_SYSTEM_SET_PROT

Adds PTA_SYSTEM_SET_PROT to support changing protection of already
established memory mappings.

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

show more ...

core: pta_system: ta binary handling

Adds support to open, close and map a TA binary from a user TA.

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

core: pta_system: ta binary handling

Adds support to open, close and map a TA binary from a user TA.

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

show more ...

libutee: support dynamic memory mapping

Adds tee_map_zi() and tee_unmap() as wrappers for PTA_SYSTEM_MAP_ZI and
PTA_SYSTEM_UNMAP respectively.

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

libutee: support dynamic memory mapping

Adds tee_map_zi() and tee_unmap() as wrappers for PTA_SYSTEM_MAP_ZI and
PTA_SYSTEM_UNMAP respectively.

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

show more ...

core: pta_system: support dynamic memory mapping

Adds PTA_SYSTEM_MAP_ZI and PTA_SYSTEM_UNMAP to dynamically map and unmap
user space memory from user space. The memory is automatically freed
when th

core: pta_system: support dynamic memory mapping

Adds PTA_SYSTEM_MAP_ZI and PTA_SYSTEM_UNMAP to dynamically map and unmap
user space memory from user space. The memory is automatically freed
when the context of the TA is freed.

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

show more ...

PTA: add support for deriving device and TA unique keys

Enable derivation of device and Trusted Application unique keys that can
be used by different Trusted Applications directly. An example of use

PTA: add support for deriving device and TA unique keys

Enable derivation of device and Trusted Application unique keys that can
be used by different Trusted Applications directly. An example of use
case could be when you need to encrypt some data in a Trusted App and
then give it back to normal world.

By default device unique properties (HUK and TA UUID) will be used when
deriving a key. However, the one calling the PTA derive key function
also have the ability to provide some extra data that will be mixed in
together with existing device unique properties. That gives the ability
to derive keys that are not only device and Trusted Application unique,
but also tied to some additional data, it could for example be a
password or something similar.

Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

libutee: arm64: Add support for function tracing of user TAs

Function tracing (ftrace) is a useful debugging technique to dump
function call graph for in-depth analysis of program execution and also

libutee: arm64: Add support for function tracing of user TAs

Function tracing (ftrace) is a useful debugging technique to dump
function call graph for in-depth analysis of program execution and also
to get useful information in case of any program abort.

In case of TA, this function graph information is dumped in a buffer
kept in .bss section of corresponding instrumented TA. So this buffer
can be dumped to normal world in case TA session closes or in case of
any abort. Also size of this ftrace buffer is configurable per TA via
following config option during TA compilation:

CFG_FTRACE_BUF_SIZE=2048

Function tracing is completely optional debugging feature which could
be enabled via command line config option CFG_TA_FTRACE_SUPPORT=y.

Along with this user needs to add cflag: "-pg" to the files for whom
function graph is to be generated. Typically for the whole TA, it should
be compiled with CFG_TA_MCOUNT=y.

And in case user wants to set "-pg" for particular file, following should
go in corresponding sub.mk:

cflags-<file-name>-y+=-pg

Also, to generate function graph for user mode libraries enable
CFG_ULIBS_MCOUNT=y which will set "-pg" for all library files.

Currently this patch adds support for function tracing of 64-bit
TAs only.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey960)

show more ...

Replace ta_head.entry with elf entry

Prior to this patch the entry function of the TA was stored in ta_head
which is located in a read-only section of the TA. This results in the
linker emitting a r

Replace ta_head.entry with elf entry

Prior to this patch the entry function of the TA was stored in ta_head
which is located in a read-only section of the TA. This results in the
linker emitting a relocation modifying a read-only section. This is a
problem if the read-only section is mapped read-only while relocations
are performed. To avoid this problematic relocation the ta_head.entry
is removed and the ELF entry point is used instead.

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

show more ...

libutee: fix deprecated TA_FLAG_REMAP_SUPPORT inline comment

Update inline comment and value for the deprecated TA flag
TA_FLAG_REMAP_SUPPORT.

Signed-off-by: Etienne Carriere <etienne.carriere@lina

libutee: fix deprecated TA_FLAG_REMAP_SUPPORT inline comment

Update inline comment and value for the deprecated TA flag
TA_FLAG_REMAP_SUPPORT.

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

show more ...

core: ignore deprecated TA flags EXEC_DDR and USER_MODE

Commit 387b0ee39b1b ("core: deprecate TA property flags EXEC_DDR and
USER_MODE") removes the requirement for user TAs to set the flags
TA_FLAG

core: ignore deprecated TA flags EXEC_DDR and USER_MODE

Commit 387b0ee39b1b ("core: deprecate TA property flags EXEC_DDR and
USER_MODE") removes the requirement for user TAs to set the flags
TA_FLAG_EXEC_DDR (bit 0) and TA_FLAG_USER_MODE (bit 1), the rationale
being that they are meaningless in the current implementation.
The macros are re-defined to be zero to reflect the fact that they have
no use. But, instead of ignoring the previous values, the TEE core now
requires that bits 0 and 1 must *not* be set. This is a problem because
it needlessly breaks backward compatibility. A TA built against OP-TEE
3.0.0 will not work with 3.1.0 or later:

E/TC:? 0 tee_ta_init_user_ta_session:1040 Invalid TA flag(s) 0x3

This commit changes the acceptable flags mask (TA_FLAGS_MASK) to
include the previous EXEC_DDR and USER_MODE bits, thus restoring
backward compatibility.

Fixes: 387b0ee39b1b ("core: deprecate TA property flags EXEC_DDR and USER_MODE")
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

core: use PTA as acronym for pseudo TA

Make inline comments and trace messages more consistent by
using PTA as acronym for pseudo TA, rather than using pTA, PTA
and pta at various places.

Signed-of

core: use PTA as acronym for pseudo TA

Make inline comments and trace messages more consistent by
using PTA as acronym for pseudo TA, rather than using pTA, PTA
and pta at various places.

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

show more ...

libutee: TEE_MemCompare(): use constant time algorithm

TEE_MemCompare() currently calls memcmp() which returns as soon as a
difference is found in the compared buffers. The fact that the
comparison

libutee: TEE_MemCompare(): use constant time algorithm

TEE_MemCompare() currently calls memcmp() which returns as soon as a
difference is found in the compared buffers. The fact that the
comparison is not constant time for a given buffer size can reveal
information on the buffer content and lead to side-channel attacks.
Although the GlobalPlatform TEE Internal Core API specification says
nothing about this timing aspect, it is unsafe not to propose a constant
time implementation to TAs. A member of the GP specification working
group confirmed in an informal discussion.

Therefore, replace memcmp() with consttime_memcmp() for constant time
comparison. If a TA needs the fastest possible buffer comparison it can
call the C library function memcmp() (from <string.h>), which we provide
in libutils.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reported-by: Bastien Simondi <bsimondi@netflix.com> [3.2]
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>

show more ...

core: pta: Add device pseudo TA

This pseudo TA enumerates OP-TEE pseudo TAs which can act as devices/
services for Linux TEE bus driver. For differentiation of such devices,
added TA_FLAG_DEVICE_ENU

core: pta: Add device pseudo TA

This pseudo TA enumerates OP-TEE pseudo TAs which can act as devices/
services for Linux TEE bus driver. For differentiation of such devices,
added TA_FLAG_DEVICE_ENUM optional flag in pseudo TA header.

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

show more ...

Remove Secure Element API support

There is probably no-one using the Secure Element API. We have never heard
anyone asking questions about it, have no way to test it and we believe
it is not even wo

Remove Secure Element API support

There is probably no-one using the Secure Element API. We have never heard
anyone asking questions about it, have no way to test it and we believe
it is not even working right now. Therefore, remove it.

- The reserved syscalls are still present, but return
TEE_ERROR_NOT_SUPPORTED
- The TEE_SE* functions (GlobalPlatform TEE Secure Element API,
GPD_SPE_024) are removed from libutee.a and the header file
tee_internal_se_api.h is removed as well

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

show more ...

utee: support prehashed RSA sign/ver without ASN.1

Add TEE Core Internal API extension TEE_ALG_RSASSA_PKCS1_V1_5 to
sign/verify pre-hashed PKCS#1 v1.5 EMSA without ASN.1 around the hash.
This relies

utee: support prehashed RSA sign/ver without ASN.1

Add TEE Core Internal API extension TEE_ALG_RSASSA_PKCS1_V1_5 to
sign/verify pre-hashed PKCS#1 v1.5 EMSA without ASN.1 around the hash.
This relies on libtomcrypt LTC_PKCS_1_V1_5_NA1. The extension can be
turned on with CFG_CRYPTO_RSASSA_NA1.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Gabor Szekely <szvgabor@gmail.com>

show more ...

core: introduce lockdep algorithm

This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:

1. A thread tries to release a

core: introduce lockdep algorithm

This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:

1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.

The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:

[Thread #1] [Thread #2]

lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...

The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.

The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.

The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:

[Thread #1] [Thread #2]

lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!

A pseudo-TA is added for testing (pta/core_lockdep_tests.c).

This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.

Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

Use inttypes.h over stdint.h on some .h files

Uses inttypes.h over stdint.h on some .h files to be nice to U-boot.

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

Use inttypes.h over stdint.h on some .h files

Uses inttypes.h over stdint.h on some .h files to be nice to U-boot.

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

show more ...

benchmark: change the way of timestamp buffer allocation.

In case if timestamp buffer is allocated in userspace and new register
user memory API is used for its registering in OP-TEE (introduced in

benchmark: change the way of timestamp buffer allocation.

In case if timestamp buffer is allocated in userspace and new register
user memory API is used for its registering in OP-TEE (introduced in
optee_client commit 27888d73d156 ("tee_client_api: register user memory")),
there is no possibility to keep this mapping permanent among different
TEEC_InvokeCommand invocations, as all SHM are automatically unmapped from
OP-TEE VA space after TEEC_InvokeCommand is handled by OP-TEE.

Timestamp buffer is now allocated with thread_rpc_alloc_global_payload().

Fixes: https://github.com/OP-TEE/optee_os/issues/1979
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>

show more ...

pta: add system pTA

Add system pTA, which provides misc. auxiliary services, extending
existing GlobalPlatform Core API.
Add a call for seeding entropy to the default RNG pool.

Reviewed-by: Jens Wi

pta: add system pTA

Add system pTA, which provides misc. auxiliary services, extending
existing GlobalPlatform Core API.
Add a call for seeding entropy to the default RNG pool.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>

show more ...

Remove license notice from STMicroelectronics files

Since a while the source files license info are defined by SPDX
identifiers. We can safely remove the verbose license text from the
files that are

Remove license notice from STMicroelectronics files

Since a while the source files license info are defined by SPDX
identifiers. We can safely remove the verbose license text from the
files that are owned by either only STMicroelectronics or only both
Linaro and STMicroelectronics.

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

show more ...