core: configuration switches to tune stack sizes

Enabling certain configuration options might increase the TMP and
THREAD stack requirements.

This commit defines CFG_ options so that the sizes of t

core: configuration switches to tune stack sizes

Enabling certain configuration options might increase the TMP and
THREAD stack requirements.

This commit defines CFG_ options so that the sizes of those two stacks
can be fine tuned at build time.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jerome Forissier <jerome@forissier.org>

show more ...

GP 1.1: Check parameters annotated in the specification

Checks that all the function parameters which are annotated in the
specification [1] are compliant with regards to memory access and memory
lo

GP 1.1: Check parameters annotated in the specification

Checks that all the function parameters which are annotated in the
specification [1] are compliant with regards to memory access and memory
location. In case the check fails the TA panics to help debugging. The
more precise and expensive checks can be disabled with
CFG_TA_STRICT_ANNOTATION_CHECKS=n.

TEE_Realloc(), TEE_MemMove(), TEE_MemCompare(), TEE_MemFill() are
skipped for performance reasons. The TA will instead die with a fatal
exception if buffers supplied to these functions do not follow the
annotation rules.

[1]: GlobalPlatform TEE Internal Core API Specification v1.1

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

show more ...

core: load stmm via secure partition

Secure variable storage for EFI variables is critical for enabling and
protecting UEFI Secure Boot. Unfortunately due to the fact that SPD and
SPM are mutually e

core: load stmm via secure partition

Secure variable storage for EFI variables is critical for enabling and
protecting UEFI Secure Boot. Unfortunately due to the fact that SPD and
SPM are mutually exclusive, we can't run StMM from EDK2 and OP-TEE.
An advantage of doing so is that different firmware implementations
can leverage EDK2's StandAloneMM and in cooperation with OP-TEE RPMB
APIs can store UEFI variables in a secure storage.
This makes the variable storage quite generic in any device with an RPMB
partition.

Using a well debugged application is preferable over rewriting the whole
application as a TA. Another advantage is that this inherits the Fault
Tolerant Writes (FTW) functionality built-in on StMM to protect
variables against corruptions during writing. Considering the FFA
changes of the future Arm architectures using an SP that includes
everything seems like a better choice at the moment.
The 'SPM emulation' currently added into OP-TEE only supports
a single SP to be launched. This means that the StMM embedded
application has the RPMB driver built in at the moment. In the future we
can add code (evolving FFA) to launch multiple SPs. So the StMM variable
handling can be decoupled from the RPMB driver, which will reside in a
different SP.

So let's add a user mode secure partition context and support loading
"Standalone MM" of EDK2 into it. A separate syscall handling is added to
serve as different kind of ABI and syscall IDs. The secure partition has
a TA like interface towards normal world, but requests are routed into
the StMM partition instead.

CFG_STMM_PATH is assigned the path of BL32_AP_MM.fd, for instance:
CFG_STMM_PATH=...Build/QemuVirtMmStandalone/DEBUG_GCC5/FV/BL32_AP_MM.fd

Since this is quite tricky to compile and test you can use this [1].
Just clone the repo and run ./build.sh. The script will pick up edk2,
edk2-platforms, op-tee, atf and U-boot and compile all the necessary
binaries for QEMU. A patch (awful hack) has been added to U-boot to
allow RPMB emulation through it's supplicant, since QEMU RPMB emulation
is not yet available.
After compiling and launching QEMU the usual U-boot commands for EFI
variable management will store the variables on an RPMB device.

[1] https://git.linaro.org/people/ilias.apalodimas/efi_optee_variables.git/

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Co-developed-by: Pipat Methavanitpong <pipat1010@gmail.com>
Signed-off-by: Pipat Methavanitpong <pipat1010@gmail.com>
Co-developed-by: Miklos Balint <Miklos.Balint@arm.com>
Signed-off-by: Miklos Balint <Miklos.Balint@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

Update revision for release tag 3.10.0-rc1

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

mk/subdir.mk: handle C++ flags related variables

Adds proper handling of cxxflags-y, cxxflags-<file name>-y,
cxxflags-remove-y, cxxflags-remove-<file name>-y, cxxflags-lib-y in the
same way as for C

mk/subdir.mk: handle C++ flags related variables

Adds proper handling of cxxflags-y, cxxflags-<file name>-y,
cxxflags-remove-y, cxxflags-remove-<file name>-y, cxxflags-lib-y in the
same way as for C flags.

Fixes: be3bc461c686 ("ta: experimental C++ support")
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: add stack overflow detection

This commit introduces CFG_CORE_DEBUG_CHECK_STACKS to check the stack
limits using compiler instrumentation (-finstrument-functions). When
enabled, the C compiler

core: add stack overflow detection

This commit introduces CFG_CORE_DEBUG_CHECK_STACKS to check the stack
limits using compiler instrumentation (-finstrument-functions). When
enabled, the C compiler will insert entry and exit hooks in all
functions in the TEE core. On entry, the stack pointer is checked and
if an overflow is detected, panic() is called.

How is this helpful since we have stack canaries already?
1. When a dead canary is found, the call stack will give no indication
of the root cause of the corruption which may have happened quite some
time before. Running the test case again with a debugger attached and a
watchpoint on the canary is not always an option.
2. The system may corrupt the stack and hang in an exception handler
before the first canary check, for instance, during boot when the
temporary stack is used. This code will likely catch such issues, too.

The downside is increased stack usage and a significant runtime overhead
which is why this feature should be enabled only for troubleshooting.

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

show more ...

ta: experimental C++ support

Update the TA makefiles to support C++ (file extension: .cpp).

This allows the use of C++ in TA and libraries, with limitations (see
below). I consider this work experi

ta: experimental C++ support

Update the TA makefiles to support C++ (file extension: .cpp).

This allows the use of C++ in TA and libraries, with limitations (see
below). I consider this work experimental because it was only tested
with simple cases in xtest, introducing the required changes and
addressing issues one after another. Therefore, some features may be
missing for more complex use cases (additional relocation types or
runtime support...).

Tested with the arm-linux-gnueabihf- and aarch64-linux-gnu- toolchains
(GCC 8.3).

Limitations:

- Clang is not supported at the moment
- Exception handling: shared libraries cannot throw, catch or propagate
exceptions. Doing so would require linking the libraries and the main
program with the shared libgcc [1] which is not straightforward due
to the many dependencies on the GNU libc. Exceptions *can* be used in
the main program however, as well as in static libraries directly
linked with the main program.
- ldelf stack unwinding does not support C++ frames so crash/panic
dumps will likely be truncated when they involve C++ code.

Link: [1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html see "-shared-libgcc"
Tested-by: Jerome Forissier <jerome@forissier.org> (QEMU, QEMUv8, HiKey960)
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 ...

mk: core: ta: Configurable Python interpreter

Build systems that manage multiple different python interpreters need
explicit control over which version of the interpreter to use.
This patch enables

mk: core: ta: Configurable Python interpreter

Build systems that manage multiple different python interpreters need
explicit control over which version of the interpreter to use.
This patch enables one to override the default interpreter with the path
to a specific one.

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

show more ...

subdir.mk: clear aflags-remove-y after processing

After processing a sub.mk by subdir.mk also clear aflags-remove-y
together with the rest of the variables to clear.

Reviewed-by: Jerome Forissier <

subdir.mk: clear aflags-remove-y after processing

After processing a sub.mk by subdir.mk also clear aflags-remove-y
together with the rest of the variables to clear.

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

show more ...

lib.mk: clang: link shared libraries with -z separate-loadable-segments

The same Clang 10 fix in commit 4d35ab6a0cef ("TA dev kit: clang: link
shared libraries with -z separate-loadable-segments") i

lib.mk: clang: link shared libraries with -z separate-loadable-segments

The same Clang 10 fix in commit 4d35ab6a0cef ("TA dev kit: clang: link
shared libraries with -z separate-loadable-segments") is needed for
locally built user space libraries when CFG_ULIBS_SHARED=y.

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

show more ...

Move CFG_WITH_STACK_CANARIES to global config file

All platforms but one (bcm-ns3) set CFG_WITH_STACK_CANARIES ?= y in
their configuration files. Move this flag to the global mk/config.mk
instead. N

Move CFG_WITH_STACK_CANARIES to global config file

All platforms but one (bcm-ns3) set CFG_WITH_STACK_CANARIES ?= y in
their configuration files. Move this flag to the global mk/config.mk
instead. Not sure it matters much, but in order to avoid any functional
change, CFG_WITH_STACK_CANARIES ?= n is added to plat-bcm/conf.mk.

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

show more ...

build: introduce ld-option macro

Adds a makefile macro to test if the linker supports a given option.

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

build: introduce ld-option macro

Adds a makefile macro to test if the linker supports a given option.

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

show more ...

Cleanup unused comp-cflags$(sm) from libgcc lookup commands

The compiler is not expected to need any flag from $(comp-cflags$(sm))
to locate the compiler runtime libraries, and in fact this variable

Cleanup unused comp-cflags$(sm) from libgcc lookup commands

The compiler is not expected to need any flag from $(comp-cflags$(sm))
to locate the compiler runtime libraries, and in fact this variable is
always undefined at the point it is used. Indeed, comp-cflags$(sm) is
set in mk/compile.mk, i.e., after mk/gcc.mk (or mk/clang.mk) has
been included.

Therefore, remove the useless flags.

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

show more ...

Allow use of cc-option in core/arch/arm/arm.mk

It can be useful to call the cc-option macro when setting flags in
core/arch/arm/arm.mk. Unfortunately cc-option is defined in
mk/compile.mk which is t

Allow use of cc-option in core/arch/arm/arm.mk

It can be useful to call the cc-option macro when setting flags in
core/arch/arm/arm.mk. Unfortunately cc-option is defined in
mk/compile.mk which is too late to be useful (core/arch/arm/arm.mk is
included by core/core.mk before mk/compile.mk).

This commit addresses the issue by moving the definition of cc-option
to its own file, mk/cc-option.mk, which is then included by
core/arch/arm/arm.mk. There is a dependency on the compiler definitions
(mk/gcc.mk or mk/clang.mk) and on $(arch-bit-$(sm)) so
core/arch/arm/arm.mk is modified accordingly.

Moving cc-option out of mk/compile.mk means that all non-core
submodules would lose the definition unless they include
mk/cc-option.mk; the TA dev kit is modified so that TAs can call
cc-option from within their sub.mk files. As for other submodules, they
are internal and do not use cc-options as of now so they are not
modified.

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

show more ...

mk/compile.mk: fix cc-option macro

There are (at least) three issues with the cc-option macro:

1. When COMPILER=clang: when presented with a supported but unused
option, Clang emits a warning to

mk/compile.mk: fix cc-option macro

There are (at least) three issues with the cc-option macro:

1. When COMPILER=clang: when presented with a supported but unused
option, Clang emits a warning to stderr (and returns a success code
of 0). Therefore it is incorrect to check stderr to determine if an
option is supported or not; we should rely on the return status
instead.
2. When COMPILER=clang, the compile command $(CC$(sm)) contains an
equal sign (e.g., clang --target=arm-linux-gnueabihf). This is not
expected in the cc-option macro, currently only flags are allowed to
potentially contain an equal sign. This messes with the caching of
the test result.
3. The macro should not cache the return value when an option is not
supported. For instance, if we have:
A := $(call cc-option,--not-supported,a)
B := $(call cc-option,--not-supported,b)
...we expect A to be "a" and B to be "b". The current implementation
returns "a" in both cases.

This commit fixes the above problems.

Fixes: 989ac108b0ef ("mk/compile.mk: add cc-option macro")
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

config.mk: fix CFG_OPTEE_REVISION_MINOR

The current release is 3.9.0, change the revision to match.

Fixes: af141c61fe7a ("Update CHANGELOG for 3.9.0")
Reviewed-by: Joakim Bech <joakim.bech@linaro.o

config.mk: fix CFG_OPTEE_REVISION_MINOR

The current release is 3.9.0, change the revision to match.

Fixes: af141c61fe7a ("Update CHANGELOG for 3.9.0")
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

clang.mk: use the compiler-rt runtime instead of libgcc

Add the `-rtlib` option to `clang -print-libgcc-file-name` so that the
compiler-rt runtime is used instead of libgcc, as the AOSP (also any
ot

clang.mk: use the compiler-rt runtime instead of libgcc

Add the `-rtlib` option to `clang -print-libgcc-file-name` so that the
compiler-rt runtime is used instead of libgcc, as the AOSP (also any
other Clang-only) build environment comes with compiler-rt but not
libgcc.

Signed-off-by: Victor Chong <victor.chong@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Tested-by: Jerome Forissier <jerome@forissier.org> (QEMUv8, Clang 9.0.1)

show more ...

mk/subdir.mk: avoid trailing slash in $(sub-dir-out)

As a general rule, paths to directories should not end with a slash
[1]. In some cases, $(sub-dir-out) does not meet this requirement. For
exampl

mk/subdir.mk: avoid trailing slash in $(sub-dir-out)

As a general rule, paths to directories should not end with a slash
[1]. In some cases, $(sub-dir-out) does not meet this requirement. For
example when building the 'crypt' TA in the optee_test project:

GEN /tmp/optee/optee_test/out/ta/crypt//ca_crt.c
CC /tmp/optee/optee_test/out/ta/crypt//ca_crt.o
GEN /tmp/optee/optee_test/out/ta/crypt//mid_crt.c
CC /tmp/optee/optee_test/out/ta/crypt//mid_crt.o
GEN /tmp/optee/optee_test/out/ta/crypt//mid_key.c
CC /tmp/optee/optee_test/out/ta/crypt//mid_key.o

In this example, $(sub-dir-out) is /tmp/optee/optee_test/out/ta/crypt/.

This patch removes the trailing slash.

[1] commit 4334e8d79fa3 ("Makefile variables $(*-dir) should not have a
trailing slash")

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

show more ...

core: clang: pager: use the normal linker (ld.lld)

Since LLVM commit [1] ("[ELF] Keep orphan section names (.rodata.foo
.text.foo) unchanged if !hasSectionsCommand"), ld.lld behaves like GNU
ld rega

core: clang: pager: use the normal linker (ld.lld)

Since LLVM commit [1] ("[ELF] Keep orphan section names (.rodata.foo
.text.foo) unchanged if !hasSectionsCommand"), ld.lld behaves like GNU
ld regarding output section names. So, we can remove our temporary hack.

This also fixes a build issue when a newer Clang (v11 master) is used
together with an older GNU ld (8.3 for instance) due to the latter not
supporting some GNU_PROPERTY_* values generated by the Clang compiler:

LD out/arm/core/tee.elf
bin/aarch64-linux-gnu-ld: warning: out/arm/core/ta_pub_key.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
...

Link: [1] https://github.com/llvm/llvm-project/commit/9e33c096476a
Signed-off-by: Jerome Forissier <jerome@forissier.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

core: clang: add --apply-dynamic-relocs linker flag

Core ASLR relies on the executable being ready to run from its
preferred load address, because some symbols are used before the MMU is
enabled and

core: clang: add --apply-dynamic-relocs linker flag

Core ASLR relies on the executable being ready to run from its
preferred load address, because some symbols are used before the MMU is
enabled and relocations are applied. Clang (ld.lld) on Aarch64 needs a
special flag for this: --apply-dynamic-relocs. Without the flag the
R_AARCH64_RELATIVE places are initially filled with zeros.

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

show more ...

core: RPMB FS: Caching for FAT FS entries

This patch adds optional FAT FS entry caching functionality to the
RPMB FS. This functionality can be enabled by a non zero value for
CFG_RPMB_FS_CACHE_ENTR

core: RPMB FS: Caching for FAT FS entries

This patch adds optional FAT FS entry caching functionality to the
RPMB FS. This functionality can be enabled by a non zero value for
CFG_RPMB_FS_CACHE_ENTRIES. The caching functionality can improve RPMB
I/O at the cost of additional heap memory. The cache size is most
likely platform-specific and should be chosen according to available
secure world memory and expected FAT FS entries in RPMB. The cache
holds the first X FAT FS entry in RAM. Whenever the FAT FS is
traversed, we read from the cache instead of invoking RPMB I/O. The
cache is updated when cached FAT FS entries are written.

Signed-off-by: Manuel Huber <mahuber@microsoft.com>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
Tested-by: Jerome Forissier <jerome@forissier.org> (HiKey960, GP)

show more ...

mk: clang.mk: use 'clang -E' instead of clang-cpp

AOSP's prebuilt versions of Clang [1] don't contain the clang-cpp
symlink to clang, so use the equivalent command of 'clang -E' instead.

LINK: [1]

mk: clang.mk: use 'clang -E' instead of clang-cpp

AOSP's prebuilt versions of Clang [1] don't contain the clang-cpp
symlink to clang, so use the equivalent command of 'clang -E' instead.

LINK: [1] https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/master
LINK: [2] https://github.com/llvm/llvm-project/tree/llvmorg-9.0.1
LINK: [3] https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/master/clang-r370808/bin/clang

Suggested by: Jerome Forissier <jerome@forissier.org>
Signed-off-by: Victor Chong <victor.chong@linaro.org>
Tested-by: Victor Chong <victor.chong@linaro.org> (builds only with
clang-v9.0.1 [2] and AOSP clang v10.0.1 [3])
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>

show more ...

mk/clang.mk: define libgcc$(sm)

Adds missing definition for libgcc$(sm) (the compiler runtime library)
to mk/clang.mk.

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

mk/clang.mk: define libgcc$(sm)

Adds missing definition for libgcc$(sm) (the compiler runtime library)
to mk/clang.mk.

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

show more ...

core: lockdep: introduce CFG_LOCKDEP_RECORD_STACK

The lockdep algorithm uses quite a bit of heap memory to record the
call stacks. This commit adds a configuration flag so that this may be
turned of

core: lockdep: introduce CFG_LOCKDEP_RECORD_STACK

The lockdep algorithm uses quite a bit of heap memory to record the
call stacks. This commit adds a configuration flag so that this may be
turned off. When CFG_LOCKDEP_RECORD_STACK=n the deadlock detection
still works but the diagnostics message will show no call stack
obviously.

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

show more ...

drivers/scmi-msg: smt entry points for incoming messages

This change implements SCMI channels for reading a SCMI message from a
shared memory and call the SCMI message drivers to route the message
t

drivers/scmi-msg: smt entry points for incoming messages

This change implements SCMI channels for reading a SCMI message from a
shared memory and call the SCMI message drivers to route the message
to the target platform services.

SMT refers to the shared memory management protocol which is used
to get/put message/response in shared memory. SMT is a 28byte header
stating shared memory state and exchanged protocol data.

The processing entry for a SCMI message can be a secure interrupt
(CFG_SCMI_MSG_SMT_INTERRUPT_ENTRY=y), and fastcall SMC
(CFG_SCMI_MSG_SMT_FASTCALL_ENTRY=y) or a threaded execution
context entry (CFG_SCMI_MSG_SMT_THREAD_ENTRY=y).

SMT description in this implementation is based on the SCP-firmware
implementation [1].

Link: [1] https://github.com/ARM-software/SCP-firmware.git

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

show more ...