Generate ELF Note for BTI in all arm64 asm files

Add program property note section in the assembly files to
ensure that when linking them, program property note section
is generated in the final ELF

Generate ELF Note for BTI in all arm64 asm files

Add program property note section in the assembly files to
ensure that when linking them, program property note section
is generated in the final ELF.

Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

ldelf: Add support for mapping ELF executable sections as guarded

Introduce LDELF_MAP_FLAG_BTI to indicate if ELF supports BTI. A
BTI instruction is used to guard against the execution of instructio

ldelf: Add support for mapping ELF executable sections as guarded

Introduce LDELF_MAP_FLAG_BTI to indicate if ELF supports BTI. A
BTI instruction is used to guard against the execution of instructions
that are not the intended target of a branch. The executable pages need
to be marked as guarded to ensure that BTI doesn't execute as NOP.

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

show more ...

ldelf: Add ELF program property parsing support to check for BTI

ELF program properties will be needed for detecting whether to
enable optional architecture or ABI features for a new ELF process.

T

ldelf: Add ELF program property parsing support to check for BTI

ELF program properties will be needed for detecting whether to
enable optional architecture or ABI features for a new ELF process.

The PT_GNU_PROPERTY is generated by a linker to describe the
.note.gnu.property section. The definition of PT_GNU_PROPERTY can
be found in [1].

For AArch64, GNU_PROPERTY_AARCH64_FEATURE_1_AND program property type
describes a set of processor features with which an ELF object or
executable image is compatible, but does not require in order to
execute correctly. These processor features are BTI and PAC.

[1] https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf

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

show more ...

Move section .note.gnu.property after .text in lds files

It is observed that clang compiler sometimes places the
.note.gnu.property at offset 0. For TA's, the loader expects
the user_ta_header at th

Move section .note.gnu.property after .text in lds files

It is observed that clang compiler sometimes places the
.note.gnu.property at offset 0. For TA's, the loader expects
the user_ta_header at that location while for ldelf,
_ldelf_start() is expected at this point. To avoid such
conflicts place this section after the text section.

Signed-off-by: Ruchika Gupta <ruchika.gupta@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

util: rename ALIGNMENT_IS_OK to IS_ALIGNED_WITH_TYPE

Implement the renamed macro using the IS_ALIGNED definition.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Etienne Carrie

util: rename ALIGNMENT_IS_OK to IS_ALIGNED_WITH_TYPE

Implement the renamed macro using the IS_ALIGNED definition.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

build: ldelf and TAs can rely on CFLAGS32/CFLAGS64

Defines arch-bits-$(sm) for ldelf and intree TAs sub components
so that they can build using CFLAGS32 (or CFLAGS64) directives
possibly passed by t

build: ldelf and TAs can rely on CFLAGS32/CFLAGS64

Defines arch-bits-$(sm) for ldelf and intree TAs sub components
so that they can build using CFLAGS32 (or CFLAGS64) directives
possibly passed by the build environment.

Defines arch-bits-ta_arm32 (resp. 64) in TA devkit to leverage
CFLAGS32 (reps. CFLAGS64) directive passed by the build process. This
change is needed for external package willing to pass specific
directive to TA build sequence as toolchain's sysroot path.

Adds an inline comment describing $(sm) value in the in tree TAs build
instructions.

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

show more ...

ldelf: check presence of sym_tab in e32_relocate()

Adds checks in e32_relocate() that sym_tab is assigned a symbol table
before using it.

This fixes coverity scan:
CID 1501826 (#1 of 3): Explicit n

ldelf: check presence of sym_tab in e32_relocate()

Adds checks in e32_relocate() that sym_tab is assigned a symbol table
before using it.

This fixes coverity scan:
CID 1501826 (#1 of 3): Explicit null dereferenced (FORWARD_NULL)
CID 1501826 (#2 of 3): Explicit null dereferenced (FORWARD_NULL)
CID 1501826 (#3 of 3): Explicit null dereferenced (FORWARD_NULL)

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

show more ...

core: Rename abort_print_current_ta

Rename abort_print_current_ta to abort_print_current_ts as it is used by
both SPs and TAs.

Signed-off-by: Jelle Sels <jelle.sels@arm.com>
Reviewed-by: Jens Wikla

core: Rename abort_print_current_ta

Rename abort_print_current_ta to abort_print_current_ts as it is used by
both SPs and TAs.

Signed-off-by: Jelle Sels <jelle.sels@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

ldelf: assert result in print_seg()

Adds a few assert() that snprintf() succeeds in print_seg().

This fixes coverity scan:
CID 1501815 (#4 of 4): Unchecked return value (CHECKED_RETURN)

Reviewed-

ldelf: assert result in print_seg()

Adds a few assert() that snprintf() succeeds in print_seg().

This fixes coverity scan:
CID 1501815 (#4 of 4): Unchecked return value (CHECKED_RETURN)

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

show more ...

core: ldelf: implement separate syscalls for ldelf

Implements a separate syscall handler for ldelf to decouple it from user
TAs and enable using it for all TSs. The calling convention is the same
as

core: ldelf: implement separate syscalls for ldelf

Implements a separate syscall handler for ldelf to decouple it from user
TAs and enable using it for all TSs. The calling convention is the same
as for utee_* syscalls. To distinguish between the different SVCs, the
syscall handler pointer is updated before entering ldelf and restored
after returning. The step of opening a system PTA session and invoking
the commands there is eliminated, the necessary functionality is
implemented in the ldelf syscall functions.

Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>

show more ...

ldelf: use libunw

Drop ldelf/unwind_arm32,64}.c and use common code from libunw instead.

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

ldelf: use libunw

Drop ldelf/unwind_arm32,64}.c and use common code from libunw instead.

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

show more ...

ldelf: arm64: support R_AARCH64_NONE relocations

Add support for relocation type R_AARCH64_NONE indicating no
relocation is needed. No issue have been currently reported
on 64bit machines but the is

ldelf: arm64: support R_AARCH64_NONE relocations

Add support for relocation type R_AARCH64_NONE indicating no
relocation is needed. No issue have been currently reported
on 64bit machines but the issue was found with 32bit TAs that
were built with GCC 9 and were illegitimately refused to be loaded.

Linker that generates the TA executable usually does not add such
relocation type entries in the relocation table as it adds
no real value at run or debug time. This change ensures that if
such entries remain in a TA, it is still loadable.

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

show more ...

ldelf: arm32: support R_ARM_NONE relocations

Fixes an issue when the toolchain used to build a TA creates
R_ARM_NONE entries in the relocation table. Such relocation
type means that no relocation is

ldelf: arm32: support R_ARM_NONE relocations

Fixes an issue when the toolchain used to build a TA creates
R_ARM_NONE entries in the relocation table. Such relocation
type means that no relocation is expected but the relocation
table parser did not handle this type prior this change and TAs
with such entries failed to be loaded with an error message like:

E/LD: e32_relocate:378 Unknown relocation type 0

It appears that GCC 9 (at least GCC-9.2 and GCC-9.3) creates such
entries while prior version of the GCC toolchain did not.

Linker that generates the TA executable usually does not add such
relocation type entries in the relocation table as it adds
no real value at run or debug time. This change ensures that if
such entries remain in a TA, it is still loadable.

Fixes: https://github.com/OP-TEE/optee_os/issues/4064
Tested-by: Etienne Carriere <etienne.carriere@linaro.org> (stm32mp1, qemu)
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>

show more ...

ldelf: arm64: support R_AARCH64_TLSDESC relocations

When compiling the __thread test in optee_test (xtest 1029), GCC 8.3
emits R_AARCH64_TLS_TPREL relocations while GCC 6 and 7 generate
R_AARCH64_TL

ldelf: arm64: support R_AARCH64_TLSDESC relocations

When compiling the __thread test in optee_test (xtest 1029), GCC 8.3
emits R_AARCH64_TLS_TPREL relocations while GCC 6 and 7 generate
R_AARCH64_TLSDESC instead. The latter are quite easy to implement once
the former are done so add the required code to ldelf. This also
enables the C++ tests (xtest 1031) to pass with the older compilers.

Signed-off-by: Jerome Forissier <jerome@forissier.org>
Tested-by: Jerome Forissier <jerome@forissier.org> (QEMUv8, GCC 6.2/7.2)
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

ldelf: increase heap size from 12 to 16 KiB

Preparing for C++ support in TAs.

The current ldelf heap is barely sufficient to run some tests such as
xtest 1022 (dlopen()) when CFG_ULIBS_SHARED=y. If

ldelf: increase heap size from 12 to 16 KiB

Preparing for C++ support in TAs.

The current ldelf heap is barely sufficient to run some tests such as
xtest 1022 (dlopen()) when CFG_ULIBS_SHARED=y. If slightly larger
section headers are present (such as when introducing Thread Local
Storage tests, needed for C++), the heap becomes too small and the TA
fails to load.

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, libutee: rework support of DT_INIT_ARRAY/DT_FINI_ARRAY

Now that we have the standard function dl_iterate_phdr() in libutee, we
can use it to process the initialization and finalization arrays

ldelf, libutee: rework support of DT_INIT_ARRAY/DT_FINI_ARRAY

Now that we have the standard function dl_iterate_phdr() in libutee, we
can use it to process the initialization and finalization arrays in the
ELF files and deprecate the ad-hoc structure __init_fini_info
introduced in commit dd655cb9906c ("ldelf, ta: add support for
DT_INIT_ARRAY and DT_FINI_ARRAY") [1].
Unfortunately, removing __init_fini_info is not an option if we want to
ensure backward compatibility. This concerns only TAs which use ELF
initialization and/or finalization functions.

[1] Released in version 3.9.0.

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

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

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

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

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

libutee, ldelf: add leading underscore to syscall wrappers

libutee defines assembler wrapper functions for each OP-TEE system call.
These wrappers have a utee_ prefix. This commit adds a leading
und

libutee, ldelf: add leading underscore to syscall wrappers

libutee defines assembler wrapper functions for each OP-TEE system call.
These wrappers have a utee_ prefix. This commit adds a leading
underscore so that the names cannot clash with user-defined symbols.
Doing so is common practice for "system" libraries, as defined by the C
standard in a set of requirements that can be summarized as follows
(excerpt from the GNU libc documentation [1]):

[R]eserved names include all external identifiers (global functions
and variables) that begin with an underscore (‘_’) and all identifiers
regardless of use that begin with either two underscores or an
underscore followed by a capital letter are reserved names. This is so
that the library and header files can define functions, variables, and
macros for internal purposes without risk of conflict with names in
user programs.

The utee_*() wrappers are internal to OP-TEE and are not supposed to be
called directly by TAs so this should not have any user-visible impact.

Link: [1] https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

ldelf: arm64: do not unwind past end of stack

unwind_arm64() currently does not check the value of the frame pointer
after it has done its job unwinding one frame. A NULL value indicates
the end of

ldelf: arm64: do not unwind past end of stack

unwind_arm64() currently does not check the value of the frame pointer
after it has done its job unwinding one frame. A NULL value indicates
the end of the call stack, and therefore the function should return
false to stop the caller from unwinding further (a do .. while loop is
used in print_stack_arm64()). Instead invalid values for FP and PC are
returned which causes an erroneous display and the unwind stops one
step too late, when the FP is found to be outside the stack.

Fixes the invalid last line in call stacks such as xtest 1019:

E/TC:? 0 TA panicked with code 0x0
E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b
E/LD: arch: aarch64
[...]
E/LD: Call stack:
E/LD: 0x0000000080062a50
E/LD: 0x00000000801df848
E/LD: 0x00000000800631a8
E/LD: 0xfffffffffffffffc

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

show more ...