Merge "feat(aarch64): add stack debug information to assembly routines" into integration

feat(aarch64): add stack debug information to assembly routines

Debugging assembly is painful as it is, and having no useful stack trace
does not help. Code must emit CFI directives whenever the sta

feat(aarch64): add stack debug information to assembly routines

Debugging assembly is painful as it is, and having no useful stack trace
does not help. Code must emit CFI directives whenever the stack moves to
enable stack traces. Otherwise, the layout of the stack frame is
ambiguous, the debugger gives up, and shows nothing. The compiler does
this automatically for C but not assembly.

Add this information to the (currently unused) func_prologue macro.

Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ief5fd672285df8d9d90fa6a2214b5c6e45eddd81

show more ...

Merge "fix(ras): do not put RAS check before esb macro" into integration

fix(ras): do not put RAS check before esb macro

Macro esb used in TF-A executes the instruction "esb" and is kept under
RAS_EXTENSION macro. RAS_EXTENSION, as it stands today, is only enabled
for pl

fix(ras): do not put RAS check before esb macro

Macro esb used in TF-A executes the instruction "esb" and is kept under
RAS_EXTENSION macro. RAS_EXTENSION, as it stands today, is only enabled
for platforms which wants RAS errors to be handled in Firmware while esb
instruction is available when RAS architecture feature is present
irrespective of its handling.
Currently TF-A does not have mechanism to detect whether RAS is present
or not in HW, define this macro unconditionally.

Its harmless for non-RAS cores as this instruction executes as NOP.

Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I556f2bcf5669c378bda05909525a0a4f96c7b336

show more ...

Merge changes from topic "feat_state_part4" into integration

* changes:
refactor(cpufeat): enable FEAT_RNG for FEAT_STATE_CHECKED
refactor(cpufeat): align FEAT_SEL2 to new feature handling
ref

Merge changes from topic "feat_state_part4" into integration

* changes:
refactor(cpufeat): enable FEAT_RNG for FEAT_STATE_CHECKED
refactor(cpufeat): align FEAT_SEL2 to new feature handling
refactor(cpufeat): enable FEAT_NV2 for FEAT_STATE_CHECKED
refactor(cpufeat): enable FEAT_TWED for FEAT_STATE_CHECKED
refactor(cpufeat): enable FEAT_CSV2_2 for FEAT_STATE_CHECKED
refactor(cpufeat): enable FEAT_ECV for FEAT_STATE_CHECKED
refactor(cpufeat): enable FEAT_PAN for FEAT_STATE_CHECKED
refactor(cpufeat): align FEAT_SB to new feature handling
refactor(cpufeat): use alternative encoding for "SB" barrier
refactor(cpufeat): enable SYS_REG_TRACE for FEAT_STATE_CHECKED
fix(cpufeat): make stub enable functions "static inline"
fix(mpam): feat_detect: support major/minor

show more ...

refactor(cpufeat): use alternative encoding for "SB" barrier

The "sb" barrier instruction is a rather new addition to the AArch64
instruction set, so it is not recognised by all toolchains. On top o

refactor(cpufeat): use alternative encoding for "SB" barrier

The "sb" barrier instruction is a rather new addition to the AArch64
instruction set, so it is not recognised by all toolchains. On top of
that, the GNU assembler denies this instruction, unless a compatible
processor is selected:
asm_macros.S:223: Error: selected processor does not support `sb'

Provide an alternative encoding of the "sb" instruction, by using a
system register write, as this is the group where the barrier
instructions borrow their encoding space from.
This results in the exact same opcode to be generated, and any
disassembler will decode this instruction as "sb".

Change-Id: I5f44c8321e0cc04c784e02bd838e964602a96a8e
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

Merge "fix(security): optimisations for CVE-2022-23960" into integration

fix(security): optimisations for CVE-2022-23960

Optimised the loop workaround for Spectre_BHB mitigation:
1. use of speculation barrier for cores implementing SB instruction.
2. use str/ldr instead

fix(security): optimisations for CVE-2022-23960

Optimised the loop workaround for Spectre_BHB mitigation:
1. use of speculation barrier for cores implementing SB instruction.
2. use str/ldr instead of stp/ldp as the loop uses only X2 register.

Signed-off-by: Bipin Ravi <bipin.ravi@arm.com>
Change-Id: I8ac53ea1e42407ad8004c1d59c05f791011f195d

show more ...

Merge "refactor(aarch64): remove `FEAT_BTI` architecture check" into integration

refactor(aarch64): remove `FEAT_BTI` architecture check

BTI instructions are a part of the NOP space in earlier architecture
versions, so it's not inherently incorrect to enable BTI code
or instruct

refactor(aarch64): remove `FEAT_BTI` architecture check

BTI instructions are a part of the NOP space in earlier architecture
versions, so it's not inherently incorrect to enable BTI code
or instructions even if the target architecture does not support them.

This change reduces our reliance on architecture versions when checking
for features.

Change-Id: I79f884eec3d65978c61e72e4268021040fd6c96e
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "arch: Enable `FEAT_SB` for supported non-Armv8.5-A platforms" into integration

arch: Enable `FEAT_SB` for supported non-Armv8.5-A platforms

The speculation barrier feature (`FEAT_SB`) was introduced with and
made mandatory in the Armv8.5-A extension. It was retroactively made

arch: Enable `FEAT_SB` for supported non-Armv8.5-A platforms

The speculation barrier feature (`FEAT_SB`) was introduced with and
made mandatory in the Armv8.5-A extension. It was retroactively made
optional in prior extensions, but the checks in our code-base do not
reflect that, assuming that it is only available in Armv8.5-A or later.

This change introduces the `ENABLE_FEAT_SB` definition, which derives
support for the `sb` instruction in the assembler from the feature
flags passed to it. Note that we assume that if this feature is enabled
then all the cores in the system support it - enabling speculation
barriers for only a subset of the cores is unsupported.

Signed-off-by: Chris Kay <chris.kay@arm.com>
Change-Id: I978ed38829385b221b10ba56d49b78f4756e20ea

show more ...

Merge "Use Speculation Barrier instruction for v8.5 cores" into integration

Use Speculation Barrier instruction for v8.5 cores

Change-Id: Ie1018bfbae2fe95c699e58648665baa75e862000
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

Merge "Prevent speculative execution past ERET" into integration

Prevent speculative execution past ERET

Even though ERET always causes a jump to another address, aarch64 CPUs
speculatively execute following instructions as if the ERET
instruction was not a jump

Prevent speculative execution past ERET

Even though ERET always causes a jump to another address, aarch64 CPUs
speculatively execute following instructions as if the ERET
instruction was not a jump instruction.
The speculative execution does not cross privilege-levels (to the jump
target as one would expect), but it continues on the kernel privilege
level as if the ERET instruction did not change the control flow -
thus execution anything that is accidentally linked after the ERET
instruction. Later, the results of this speculative execution are
always architecturally discarded, however they can leak data using
microarchitectural side channels. This speculative execution is very
reliable (seems to be unconditional) and it manages to complete even
relatively performance-heavy operations (e.g. multiple dependent
fetches from uncached memory).

This was fixed in Linux, FreeBSD, OpenBSD and Optee OS:
https://github.com/torvalds/linux/commit/679db70801da9fda91d26caf13bf5b5ccc74e8e8
https://github.com/freebsd/freebsd/commit/29fb48ace4186a41c409fde52bcf4216e9e50b61
https://github.com/openbsd/src/commit/3a08873ece1cb28ace89fd65e8f3c1375cc98de2
https://github.com/OP-TEE/optee_os/commit/abfd092aa19f9c0251e3d5551e2d68a9ebcfec8a

It is demonstrated in a SafeSide example:
https://github.com/google/safeside/blob/master/demos/eret_hvc_smc_wrapper.cc
https://github.com/google/safeside/blob/master/kernel_modules/kmod_eret_hvc_smc/eret_hvc_smc_module.c

Signed-off-by: Anthony Steinhauser <asteinhauser@google.com>
Change-Id: Iead39b0b9fb4b8d8b5609daaa8be81497ba63a0f

show more ...

Merge "Add support for Branch Target Identification" into integration

Add support for Branch Target Identification

This patch adds the functionality needed for platforms to provide
Branch Target Identification (BTI) extension, introduced to AArch64
in Armv8.5-A by add

Add support for Branch Target Identification

This patch adds the functionality needed for platforms to provide
Branch Target Identification (BTI) extension, introduced to AArch64
in Armv8.5-A by adding BTI instruction used to mark valid targets
for indirect branches. The patch sets new GP bit [50] to the stage 1
Translation Table Block and Page entries to denote guarded EL3 code
pages which will cause processor to trap instructions in protected
pages trying to perform an indirect branch to any instruction other
than BTI.
BTI feature is selected by BRANCH_PROTECTION option which supersedes
the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication
and is disabled by default. Enabling BTI requires compiler support
and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0.
The assembly macros and helpers are modified to accommodate the BTI
instruction.
This is an experimental feature.
Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3
is now made as an internal flag and BRANCH_PROTECTION flag should be
used instead to enable Pointer Authentication.
Note. USE_LIBROM=1 option is currently not supported.

Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>

show more ...

Merge changes from topic "sm/fix_a76_errata" into integration

* changes:
Workaround for cortex-A76 errata 1286807
Cortex-A76: workarounds for errata 1257314, 1262606, 1262888, 1275112

Workaround for cortex-A76 errata 1286807

The workaround for Cortex-A76 errata #1286807 is implemented
in this patch.

Change-Id: I6c15af962ac99ce223e009f6d299cefb41043bed
Signed-off-by: Soby Mathew

Workaround for cortex-A76 errata 1286807

The workaround for Cortex-A76 errata #1286807 is implemented
in this patch.

Change-Id: I6c15af962ac99ce223e009f6d299cefb41043bed
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

show more ...

Merge pull request #1726 from antonio-nino-diaz-arm/an/includes

Sanitise includes across codebase

Sanitise includes across codebase

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- inclu

Sanitise includes across codebase

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}

The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).

For example, this patch had to be created because two headers were
called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a282 ("drivers: add tzc380 support").

This problem was introduced in commit 4ecca33988b9 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.

Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.

Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

Reorganize architecture-dependent header files

The architecture dependant header files in include/lib/${ARCH} and
include/common/${ARCH} have been moved to /include/arch/${ARCH}.

Change-Id: I96f30f

Reorganize architecture-dependent header files

The architecture dependant header files in include/lib/${ARCH} and
include/common/${ARCH} have been moved to /include/arch/${ARCH}.

Change-Id: I96f30fdb80b191a51448ddf11b1d4a0624c03394
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...