ldelf, libutee: add minimal Thread Local Storage support

Preparing for C++ support in TAs.

Adds enough runtime Thread Local Storage (TLS) support for the GNU C++
compilers (arm-linux-gnueabihf-g++,

ldelf, libutee: add minimal Thread Local Storage support

Preparing for C++ support in TAs.

Adds enough runtime Thread Local Storage (TLS) support for the GNU C++
compilers (arm-linux-gnueabihf-g++, aarch64-linux-gnu-g++) to work with
OP-TEE. That is:

- A Thread Control Block,
- The __tls_get_addr() and dl_iterate_phdr() functions.

Note that __tls_get_addr() is an ABI helper so it has no prototype in a
user-accessible header file. dl_iterate_phdr() however is defined in
<link.h> and may be used in a TA. The file lib/libutee/include/link.h is
borrowed from Android's Bionic [1] with minor changes (added the
required #include statement and named the function parameters). A
similar <link.h> header is provided by other C libraries such as GNU
libc, musl and FreeBSD/NetBSD/OpenBSD.

Link: [1] https://android.googlesource.com/platform/bionic/+/master/libc/include/link.h
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

libutee: add <elf.h>

Preparing for C++ support in TAs.

Adds header file <elf.h> in addition to <elf32.h> and <elf64.h>. This
file defines the various Elf types depending on the current
architecture

libutee: add <elf.h>

Preparing for C++ support in TAs.

Adds header file <elf.h> in addition to <elf32.h> and <elf64.h>. This
file defines the various Elf types depending on the current
architecture. In other words: when building for Aarch32 Elf_* is defined
as Elf32_*, but when building for Aarch64 it is defined as Elf64_*. This
will be useful for programs which need to examine their own structure
via dl_iterate_phdr() (which will come in a later commit).

Note: <elf.h> serves the same purpose as FreeBSD's <sys/elf.h> but does
it differently; the file is not imported from FreeBSD.

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

show more ...

Move ELF headers from ldelf/ to lib/libutee/

Preparing for C++ support in TAs.

Moves the ELF headers (elf32.h, elf64.h, elf_common.h) from
ldelf/include to lib/libutee/include so that they may be u

Move ELF headers from ldelf/ to lib/libutee/

Preparing for C++ support in TAs.

Moves the ELF headers (elf32.h, elf64.h, elf_common.h) from
ldelf/include to lib/libutee/include so that they may be used
by libutee to implement the dl_iterate_phdr() function. This will be
done in a later commit.

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

show more ...

libutee: arm64: add read_tpidr_el0() and write_tpidr_el0() macros

Preparing for C++ support in TAs.

Adds macros to <arm64_user_sysreg.h> to access TPIDR_EL0, the EL0 Read/
Write Software Thread ID

libutee: arm64: add read_tpidr_el0() and write_tpidr_el0() macros

Preparing for C++ support in TAs.

Adds macros to <arm64_user_sysreg.h> to access TPIDR_EL0, the EL0 Read/
Write Software Thread ID Register.

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

show more ...

core: arm64: preserve user space TPIDR_EL0

Preparing for C++ support in TAs.

Preserves the value of TPIDR_EL0 set by user space by saving and
restoring the register in case of syscall or foreign in

core: arm64: preserve user space TPIDR_EL0

Preparing for C++ support in TAs.

Preserves the value of TPIDR_EL0 set by user space by saving and
restoring the register in case of syscall or foreign interrupt.

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

show more ...

ldelf: arm64: support R_AARCH64_TLS_TPREL relocations

Preparing for C++ support in TAs.

This commit adds support for relocation type R_AARCH64_TLS_TPREL.
Although OP-TEE does not support multi-thre

ldelf: arm64: support R_AARCH64_TLS_TPREL relocations

Preparing for C++ support in TAs.

This commit adds support for relocation type R_AARCH64_TLS_TPREL.
Although OP-TEE does not support multi-threaded TAs, introducing basic
support for multi-threading will allow binaries generated by the
aarch64-linux-gnueabihf-g++ compiler to work properly. Indeed, this
compiler is configured for a multi-threadded environment by default.

The way R_AARCH64_TLS_TPREL works is simple: the runtime library needs
to keep a per-thread copy of all the TLS segments in the application.
When the compiler needs to access a thread-specific symbol, it emits
this relocation. The loader will then replace the value by the offset
of the desired symbol in the Thread Control Block of the current thread
(the address of the TCB is obtained via the TPIDR_EL0 register).

The runtime code that sets up the TCB from the TLS segments will come
in a later commit.

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

show more ...

ldelf: arm: support R_ARM_TLS_DTPMOD32 and R_ARM_TLS_DTPOFF32 relocations

Preparing for C++ support in TAs.

This commit adds support for Thread Local Storage (TLS) relocation
types R_ARM_TLS_DTPMOD

ldelf: arm: support R_ARM_TLS_DTPMOD32 and R_ARM_TLS_DTPOFF32 relocations

Preparing for C++ support in TAs.

This commit adds support for Thread Local Storage (TLS) relocation
types R_ARM_TLS_DTPMOD32 and R_ARM_TLS_DTPOFF32.

OP-TEE does not support multi-threaded TAs so in principle there is no
need to handle the TLS relocations. However, this commit will allow to
run C++ TAs built with the "official" arm-linux-gnueabihf compiler
(which is built with threading support enabled), as long as no
multi-thread feature is explicitly used by the TA. In other words, it
avoids the need to re-build a toolchain with --disable-threads.

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

show more ...

ldelf: add support for weak symbols

Preparing for C++ support in TAs.

When ldelf performs a symbol lookup in a TA, it currently considers
only global symbols that are not undefined. It turns out th

ldelf: add support for weak symbols

Preparing for C++ support in TAs.

When ldelf performs a symbol lookup in a TA, it currently considers
only global symbols that are not undefined. It turns out that g++ can
generates dynamic relocations referencing symbols that are weak and
undefined [1], in other words: weak declarations. Those should end up
resolving to zero.

This commit updates the symbol resolution to first look for global
defined symbols, then weak defined, then weak undefined.

[1] __pthread_key_create, pthread_mutex_lock, pthread_mutex_unlock,
__gnu_Unwind_Find_exidx.

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

show more ...

libutils: add simplified fputc(), fputs(), fwrite(), write()

Preparing for C++ support in TAs.

Adds a few <stdio.h> functions to libutils:

fputc() fputs() fwrite() write()

The proposed implem

libutils: add simplified fputc(), fputs(), fwrite(), write()

Preparing for C++ support in TAs.

Adds a few <stdio.h> functions to libutils:

fputc() fputs() fwrite() write()

The proposed implementations are limited in the sense that they only
accept writing to stdout or stderr. The output goes directly to the
secure console and no difference is made between stdout and stderr.

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

show more ...

libutils: add sprintf()

Preparing for C++ support in TAs.

Implement sprintf() in libutils.

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

libutils: add sprintf()

Preparing for C++ support in TAs.

Implement sprintf() in libutils.

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

show more ...

ta: ta.ld.S: add .eh_frame_hdr and .eh_frame sections

Preparing for C++ support in TAs.

Adds .eh_frame_hdr and .eh_frame sections to the TA linker script.
Those may be generated by the C++ compiler

ta: ta.ld.S: add .eh_frame_hdr and .eh_frame sections

Preparing for C++ support in TAs.

Adds .eh_frame_hdr and .eh_frame sections to the TA linker script.
Those may be generated by the C++ compiler. The fragment is compied
from GCC's internal linker script (shown by -Wl,-verbose).

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

show more ...

ta: ta.ld.S: add .gcc_except_table section

Preparing for C++ support in TAs.

Adds a .gcc_except_table section merging the multiple entries that may
be generated by the C++ compiler. The fragment is

ta: ta.ld.S: add .gcc_except_table section

Preparing for C++ support in TAs.

Adds a .gcc_except_table section merging the multiple entries that may
be generated by the C++ compiler. The fragment is copied from GCC's
internal linker script (shown by -Wl,-verbose).

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

show more ...

ta: ta.ld.S: add .tdata and .tbss sections

Preparing for C++ support in TAs.

TA object file generated by a thread-enabled toolchain (such as g++
built without --disable-threads) may contain .tdata*

ta: ta.ld.S: add .tdata and .tbss sections

Preparing for C++ support in TAs.

TA object file generated by a thread-enabled toolchain (such as g++
built without --disable-threads) may contain .tdata* and .tbss*
sections even if the application is single threaded. Those are similar
to .data and .bss except that they are templates to be used by the
runtime code to set up Thread Local Storage data blocks.

This commit adds those two sections as well as related relocation
sections (.rel.tdata, .rel.tbss, .rela.tdata, .rela.tbss). The
fragments are copied from GCC's internal linker script (shown by
-Wl,-verbose). They are inserted next to .dynamic and .got because they
may all be part of a RELRO segment if the linker chooses to create one.
In practice there can be only one RELRO segment [1] so sections have to
be contiguous. Note that ldelf currently ignores RELRO.

[1] https://reviews.llvm.org/D40029

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

show more ...

ta: ta.ld.S: add __exidx_start and __exidx_end

Preparing for C++ support in TAs.

__exidx_start and __exidx_end are referenced by libgcc_eh.a.

Signed-off-by: Jerome Forissier <jerome@forissier.org>

ta: ta.ld.S: add __exidx_start and __exidx_end

Preparing for C++ support in TAs.

__exidx_start and __exidx_end are referenced by libgcc_eh.a.

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

show more ...

ci: shippable: use our own cache server

Shippable has a maximum build time of 1 hour for Open Source projects.
It is usually sufficient since typical build time is currently around
35 minutes, thank

ci: shippable: use our own cache server

Shippable has a maximum build time of 1 hour for Open Source projects.
It is usually sufficient since typical build time is currently around
35 minutes, thanks to caching (ccache). But it can happen that the code
is changed too much by a pull request in which case the cache is
ineffective and build time would exceed 1 hour. When a build times out,
the cache is NOT updated and there is no other choice than to manually
feed the cache with a partial build (by removing some steps in
.shippable.yml) so that the next build can be quicker, wait for the
build to succeed, then restore all the build steps. This is quite
impractical.

This commit replaces the Shippable built-in caching mechanism with our
own cache on a cloud server (currently a Digital Ocean [1] VM).
Automatic upload is triggered after 50 minutes of build time (or at the
end of the build). Therefore, if the build times out we have a
significant amount of data in the cache and restarting the build is
usually all it takes to deal with the issue.

Cache data are transferred using SSH and the cache server is configured
with the public key of the official OP-TEE OS Shippable project (the
one that is used to build pull requests).

In addition to being tolerant to time outs, this new method is usually
faster too, because the archive is streamed directly to/from the server
whereas Shippable creates a local .tar.gz file first.

For all intents and purposes I am documenting the security configuration
of the VM:
- Ubuntu 20.04 with default settings
- Dedicated user account: 'shippable'
- The OP-TEE SSH key [3] is added to ~shippable/.ssh/authorized_keys
- The login shell for user 'shippable' is /usr/sbin/rush [2] with the
following /etc/rush.rc:

debug 1

rule default
acct on
limits t10r20
umask 002
env - USER LOGNAME HOME PATH
fall-through

rule cat-to
command ^cat >[a-zA-Z0-9_\.-]+$
chdir /home/shippable
transform s@(.*)@/usr/bin/bash -c "\\1"@

rule cat-from
command ^cat [a-zA-Z0-9_\.-]+$
chdir /home/shippable
transform s@(.*)@/usr/bin/bash -c "\\1"@

[1] https://digitalocean.com/
[2] https://www.gnu.org/software/rush/
[3] https://app.shippable.com/subs/github/OP-TEE/settings

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

show more ...

ldelf: __resolve_sym(): support STT_NOTYPE

Symbols defined in a linker script are assigned type STT_NOTYPE, but
the __resolve_sym() function in ldelf only supports STT_OBJECT and
STT_FUNCTION. As a

ldelf: __resolve_sym(): support STT_NOTYPE

Symbols defined in a linker script are assigned type STT_NOTYPE, but
the __resolve_sym() function in ldelf only supports STT_OBJECT and
STT_FUNCTION. As a result, it is impossible to resolve STT_NOTYPE
symbols at runtime. This causes an error in shared libraries when
ftrace is enabled:

# Platform: QEMU
$ make CFG_FTRACE_SUPPORT=y CFLAGS_ta_arm32=-pg run

$ xtest 1019

D/LD: ldelf:134 Loading TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b
E/LD: __resolve_sym:61 Symbol type not supported
E/TC:? 0 init_with_ldelf:232 ldelf failed with res: 0xffff000a

* regression_1019 Test dynamically linked TA
regression_1000.c:1502: [...] TEEC_ERROR_NOT_SUPPORTED

This commit adds STT_NOTYPE to the supported types, handled the same way
as STT_OBJECT and STT_FUNCTION.

Fixes: 97c5ac19427b ("ldelf: check ranges in __resolve_sym()")
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

symbolize.py: infer PC from (E)LR

When translating a call stack address to source file and line number,
subtract 2 to try and reflect the PC at the time the call was made or
the exception occurred.

symbolize.py: infer PC from (E)LR

When translating a call stack address to source file and line number,
subtract 2 to try and reflect the PC at the time the call was made or
the exception occurred. This makes the calls easier to follow and
corresponds to what the GDB backtrace command (bt) does. For data or
prefetch aborts it is even more important because now we report exactly
the line that caused the abort instead of showing the next one, which
could be misleading.

As a result of this fix, the extra "nop" instruction in __ta_entry() is
not needed anymore so remove it.

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

show more ...

ldelf: arm: fix the unwind stack failure with __no_return function

Similar fix to commit 19b3fe6c5a72 ("core: arm: fix the unwind stack
failure with __no_return function") for user space.

Signed-of

ldelf: arm: fix the unwind stack failure with __no_return function

Similar fix to commit 19b3fe6c5a72 ("core: arm: fix the unwind stack
failure with __no_return function") for user space.

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

show more ...

ta: export CFG_TEE_TA_LOG_LEVEL with ?= not :=

The value of CFG_TEE_TA_LOG_LEVEL used at optee_os build time is
exported to the TA dev kit ($O/export_ta_arm{32,64}/mk/conf.mk). The
purpose is to pro

ta: export CFG_TEE_TA_LOG_LEVEL with ?= not :=

The value of CFG_TEE_TA_LOG_LEVEL used at optee_os build time is
exported to the TA dev kit ($O/export_ta_arm{32,64}/mk/conf.mk). The
purpose is to provide a default value to the TA build environment,
which can easily be changed from the command line ("make
CFG_TEE_TA_LOG_LEVEL=3" for example).

However the following TA Makefile won't behave as expected:

BINARY := <somme uuid>
CFG_TEE_TA_LOG_LEVEL := 3 # Ignored!
include $(TA_DEV_KIT_DIR)/mk/ta_dev_kit.mk

This commit changes := to ?= so that ta_dev_kit.mk won't override any
value that may have been set previously in the TA Makefile or the
environment.

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

show more ...

libutee: TEE_AsymmetricSignDigest support 0 signature len

User can call TEE_AsymmetricSignDigest with a NULL signature and a valid
zero signatureLen in order to discover the size of the required
sig

libutee: TEE_AsymmetricSignDigest support 0 signature len

User can call TEE_AsymmetricSignDigest with a NULL signature and a valid
zero signatureLen in order to discover the size of the required
signature buffer (function should then return TEE_ERROR_SHORT_BUFFER and
update signatureLen with the required amount).

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

show more ...

rmpb: fix infinite recursion in dump_fat() when CFG_TEE_CORE_LOG_LEVEL=4

When CFG_TEE_CORE_LOG_LEVEL=4 and CFG_RPMB_FS=y, the TEE core crashes
with a dead stack canary message:

E/TC:0 0 Dead canar

rmpb: fix infinite recursion in dump_fat() when CFG_TEE_CORE_LOG_LEVEL=4

When CFG_TEE_CORE_LOG_LEVEL=4 and CFG_RPMB_FS=y, the TEE core crashes
with a dead stack canary message:

E/TC:0 0 Dead canary at end of 'stack_abt[3]'
E/TC:0 0 Panic at core/arch/arm/kernel/thread.c:192 <thread_check_canaries>
E/TC:0 0 TEE load address @ 0x1bd0f000
E/TC:0 0 Call stack:
E/TC:0 0 0x1bd17b3d print_kernel_stack at optee_os/core/arch/arm/kernel/unwind_arm32.c:452
E/TC:0 0 0x1bd23a07 __do_panic at optee_os/core/kernel/panic.c:32 (discriminator 1)
E/TC:0 0 0x1bd120cb thread_check_canaries at optee_os/core/arch/arm/kernel/thread.c:188 (discriminator 2)
E/TC:0 0 0x1bd12c1f thread_state_suspend at optee_os/core/arch/arm/kernel/thread.c:754
E/TC:0 0 0x1bd14610 thread_rpc at optee_os/core/arch/arm/kernel/thread_optee_smc_a32.S:227

The issue happens to be with the debug function dump_fat() which causes
infinite recursion. Fix it by doing nothing until after RPMB
initialization has completed.

Fixes: 5f68d7848fe8 ("core: RPMB FS: Caching for FAT FS entries")
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

build: fix race when generating conf.mk

This patch fixes the following error triggered by a heavily parallel build:

echo sm := ta_arm64 > .../export-ta_arm64/mk/conf.mk.tmp
/bin/bash: .../export-

build: fix race when generating conf.mk

This patch fixes the following error triggered by a heavily parallel build:

echo sm := ta_arm64 > .../export-ta_arm64/mk/conf.mk.tmp
/bin/bash: .../export-ta_arm64/mk/conf.mk.tmp: No such file or directory

Fixes: https://github.com/OP-TEE/optee_os/issues/3999
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Tested-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: arm: fix the unwind stack failure with __no_return function

unwind operation use LR instead of PC to locate unwind data. In some
case, the compiler removes all the extra instrustions after a b

core: arm: fix the unwind stack failure with __no_return function

unwind operation use LR instead of PC to locate unwind data. In some
case, the compiler removes all the extra instrustions after a branch to
__no_return function, and then LR saves the address of next function,
rather than the caller of the __no_return function, leading to unwind
failure.

The fix manually adjust the LR value to match the search algorithm so
as to locate the correct caller in unwind stack operation.

Signed-off-by: Angelina Zhao <xuemingzhao@asrmicro.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
[jf: reformat the commit description]
Signed-off-by: Jerome Forissier <jerome@forissier.org>

show more ...

core: remove the unused PM stubs

Removes the PM stubs and all references to CFG_PM_STUBS.

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

core: remove the unused PM stubs

Removes the PM stubs and all references to CFG_PM_STUBS.

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

show more ...

core: remove thread_*_handler_ptr

The thread_*_handler_ptr function pointers only holds the same constant
value. Instead of loading the function pointer from the entry functions
call the handler fun

core: remove thread_*_handler_ptr

The thread_*_handler_ptr function pointers only holds the same constant
value. Instead of loading the function pointer from the entry functions
call the handler functions directly and remove these
thread_*_handler_ptr function pointers.

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

show more ...