arm32: libutils, libutee, ta: add .note.GNU-stack section to .S files

When building for arm32 with GNU binutils 2.39, the linker outputs
warnings when linking Trusted Applications:

arm-unknown-lin

arm32: libutils, libutee, ta: add .note.GNU-stack section to .S files

When building for arm32 with GNU binutils 2.39, the linker outputs
warnings when linking Trusted Applications:

arm-unknown-linux-uclibcgnueabihf-ld.bfd: warning: utee_syscalls_a32.o: missing .note.GNU-stack section implies executable stack
arm-unknown-linux-uclibcgnueabihf-ld.bfd: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

We could silence the warning by adding the '--no-warn-execstack' option
to the TA link flags, like we did in the parent commit for the TEE core
and ldelf. Indeed, ldelf always allocates a non-executable piece of
memory for the TA to use as a stack.

However it seems preferable to comply with the common ELF practices in
this case. A better fix is therefore to add the missing .note.GNU-stack
sections in the assembler files.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-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 ...

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

libutils: provide empty __getauxval() implementation

Never version of libgcc are built with LSE implementation in mind. To
determine if LSE is available on platform it calls __getauxval(), so in
som

libutils: provide empty __getauxval() implementation

Never version of libgcc are built with LSE implementation in mind. To
determine if LSE is available on platform it calls __getauxval(), so in
some cases we can get undefined reference to __getauxval() error.

Prominent case is libgcc_eh.a library, which is used by C++ TAs. Exception
handler depends on atomic operations, so it tries to call
init_have_lse_atomics() first. This function in turn calls __getauxval(),
which causes linking error.

In the future we can make __getauxval() to return actual platform
capabilities.

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

show more ...

libutils: arm: add .cantunwind to __gnu_mcount_nc()

The __gnu_mcount_nc() function lacks proper annotation as registers are
pushed onto the stack. The unwind table information for this symbol is
the

libutils: arm: add .cantunwind to __gnu_mcount_nc()

The __gnu_mcount_nc() function lacks proper annotation as registers are
pushed onto the stack. The unwind table information for this symbol is
therefore incorrect and stack unwinding may fail in spectacular ways.
For example, xtest 1007 enters an infinite loop as ldelf tries to unwind
the call stack when the TA panics:

# Platform: QEMU
(buildhost)$ make CFG_FTRACE_SUPPORT=y CFLAGS_ta_arm32=-pg run
(qemu)$ xtest 1007
...
E/TC:? 0 TA panicked with code 0xbeef
E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b
E/LD: arch: arm
E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf)
E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00c000 flags r-xs (ldelf)
E/LD: region 2: va 0x00110000 pa 0x0e30e000 size 0x001000 flags rw-s (ldelf)
E/LD: region 3: va 0x00111000 pa 0x0e30f000 size 0x004000 flags rw-s (ldelf)
E/LD: region 4: va 0x00115000 pa 0x0e313000 size 0x001000 flags r--s
E/LD: region 5: va 0x00116000 pa 0x0e426000 size 0x003000 flags rw-s (stack)
E/LD: region 6: va 0x00149000 pa 0x00001000 size 0x02b000 flags r-xs [0] .ta_head .text .plt .rodata .gnu.hash .ARM.extab .ARM.exidx .dynsym .dynstr .hash
E/LD: region 7: va 0x00174000 pa 0x0002c000 size 0x0e7000 flags rw-s [0] .dynamic .tdata .tbss .got .rel.got .rel.plt .data .init_array .bss .rel.dyn
E/LD: region 8: va 0x00291000 pa 0x00000000 size 0x00b000 flags r-xs [1] .hash .gnu.hash .dynsym .dynstr .rel.dyn .rel.plt .plt .text .rodata .ARM.extab .ARM.exidx
E/LD: region 9: va 0x0029c000 pa 0x0000a000 size 0x002000 flags rw-s [1] .tdata .tbss .init_array .dynamic .got .data .bss
E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x00149000 (out-br/build/optee_test_ext-1.0/ta/os_test/out/5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf)
E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00291000 (out-br/build/optee_test_ext-1.0/ta/os_test_lib/out/libos_test.so)
E/LD: Call stack:
E/LD: 0x0029481c _utee_panic at optee_os/lib/libutee/arch/arm/utee_syscalls_a32.S:51
E/LD: 0x002944fc TEE_Panic at optee_os/lib/libutee/tee_api_panic.c:24
E/LD: 0x0014c494 ta_entry_panic at out-br/build/optee_test_ext-1.0/ta/os_test/os_test.c:787
E/LD: 0x00293574 __gnu_mcount_nc at optee_os/lib/libutils/ext/arch/arm/mcount_a32.S:44
E/LD: 0x00293574 __gnu_mcount_nc at optee_os/lib/libutils/ext/arch/arm/mcount_a32.S:44
E/LD: 0x00293574 __gnu_mcount_nc at optee_os/lib/libutils/ext/arch/arm/mcount_a32.S:44
[repeats indefinitely]

The bug is triggered by commit 3513f961cda0 ("arm32: fold
UNWIND(.fnstart/.fnend) into the FUNC macros"). Prior to that commit,
the unwind entry for __gnu_mcount_nc() was "0x1 [cantunwind]", probably
because the function had no .fnstart/.fnend directive.

This commit adds a .cantunwind directive to restore the previous
behavior: unwinding stops at __gnu_mcount_nc(). Since the ftrace code
overwrites LR on the stack, it seems there is no simple way to produce
correct and comprehensive stack dumps short of introducing an unwind
helper function with a knowledge of the ftrace transformation, similar
to what ftrace_return() does.

At least with this patch the unwinding code does not fail.

Fixes: 3513f961cda0 ("arm32: fold UNWIND(.fnstart/.fnend) into the FUNC macros")
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

libutils: embed AEABI personality routines upon CFG_UNWIND

Fix a TA build issue found when CFG_UNWIND=n. This issue produces a
build error trace like the below:

.../toolchains/aarch32/bin/arm-linux

libutils: embed AEABI personality routines upon CFG_UNWIND

Fix a TA build issue found when CFG_UNWIND=n. This issue produces a
build error trace like the below:

.../toolchains/aarch32/bin/arm-linux-gnueabihf-ld.bfd: .../toolchains/aarch32/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/libgcc_eh.a(unwind-arm.o): in function `__aeabi_unwind_cpp_pr0':
/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/src/gcc/libgcc/config/arm/unwind-arm.c:494: multiple definition of `__aeabi_unwind_cpp_pr0'; .../optee_os/out/arm/export-ta_arm32/lib/libutils.a(aeabi_unwind.o): .../optee_os/lib/libutils/ext/arch/arm/aeabi_unwind.c:9: first defined here
.../optee_os/out/arm/export-ta_arm32/mk/link.mk:109: recipe for target 'out/5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.elf' failed

I don't understand why toolchain support for __aeabi_unwind_cpp_pr0()
conflicts with the libutils implementation only when CFG_UNWIND=n. Yet
the current change works around the issue.

Fixes: https://github.com/OP-TEE/optee_test/issues/440
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Jerome Forissier <jerome@forissier.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

ftrace: Add support for syscall function tracer

This patch adds support for syscall tracing in TEE core. It complements
existing ftrace support for user TAs via adding trace for syscalls that
are in

ftrace: Add support for syscall function tracer

This patch adds support for syscall tracing in TEE core. It complements
existing ftrace support for user TAs via adding trace for syscalls that
are invoked by user TAs into the TEE core.

And after this patch ftrace will cover both TA and TEE core code. So lets
rename config option from CFG_TA_FTRACE_SUPPORT to CFG_FTRACE_SUPPORT.

It is optional to enable syscall trace via CFG_SYSCALL_FTRACE=y config
option in addition to CFG_FTRACE_SUPPORT=y config option.

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

show more ...

ftrace: core: prepare support for syscall ftrace

Enable compilation of ftrace library code for TEE core.

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

ftrace: core: prepare support for syscall ftrace

Enable compilation of ftrace library code for TEE core.

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

show more ...

ftrace: move ftrace code from libutee to libutils

Since TEE core and TA can share most of ftrace library code, so move
ftrace code from libutee to libutils library which is shared among TEE
core and

ftrace: move ftrace code from libutee to libutils

Since TEE core and TA can share most of ftrace library code, so move
ftrace code from libutee to libutils library which is shared among TEE
core and TA.

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

show more ...