Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
fe

Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
feat(build): allow full LTO builds with clang
refactor(build): make sorting of sections generic
feat(build): use clang as a linker
fix(build): correctly detect that an option is missing with ld_option
feat(build): pass cflags to the linker when LTO is enabled

show more ...

feat(build): pass cflags to the linker when LTO is enabled

Usually, both compiling and linking happen by calling the top level
gcc/clang binary. Also, both compilers quite specifically tell us to
pa

feat(build): pass cflags to the linker when LTO is enabled

Usually, both compiling and linking happen by calling the top level
gcc/clang binary. Also, both compilers quite specifically tell us to
pass the same flags to the compilation and linking stages when we enable
LTO. This is crucial for things like the undefined behaviour sanitiser.
Anecdotally, in working on this, there have been a fair few errors that
the compiler has only been able to catch due to warning flags being
passed to the linker and building with LTO.

This patch puts the contents of TF_CFLAGS into TF_LDFLAGS when LTO is
enabled. This is easier said than done, however, as we support building
with clang and linking with gcc (or vice versa), so CFLAGS that are
discovered for one will not work for the other. This patch works around
this by splitting all flags into a per-compiler variable. Then CFLAGS
and LDFLAGS get the contents of the correct one.

Some notable side effects: CPPFLAGS and TF_CFLAGS_$(ARCH) become empty
and are removed, although expanding them is kept as platforms set them.
Some flags become duplicate and are removed form TF_LDFLAGS (eg -O1).

The errata (--fix) flags are kept as-is but moved to cpu-ops.mk for
consistency. This is because they currently don't work with LTO and will
be addressed in a later patch.

Finally, ERROR_DEPRECATED's flags are also identical on all compilers so
don't maintain a difference.

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

show more ...

Merge "chore: update to use Arm word across TF-A" into integration

chore: update to use Arm word across TF-A

Align entire TF-A to use Arm in copyright header.

Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244
Signed-off-by: Govindraj Raja <govindraj.raja@arm.co

chore: update to use Arm word across TF-A

Align entire TF-A to use Arm in copyright header.

Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge "Disable stack protection explicitly" into integration

Disable stack protection explicitly

Explicitly disable stack protection via the "-fno-stack-protector"
compiler option when the ENABLE_STACK_PROTECTOR build option is
set to "none" (the default).

T

Disable stack protection explicitly

Explicitly disable stack protection via the "-fno-stack-protector"
compiler option when the ENABLE_STACK_PROTECTOR build option is
set to "none" (the default).

This allows the build to complete without link errors on systems where
stack protection is enabled by default in the compiler.

Change-Id: I0a676aa672815235894fb2cd05fa2b196fabb972
Signed-off-by: Simon South <simon@simonsouth.net>

show more ...

Merge changes from topic "lm/stack_protector" into integration

* changes:
juno: Add security sources for tsp-juno
Add support for default stack-protector flag

Add support for default stack-protector flag

The current stack-protector support is for none, "strong" or "all".
The default use of the flag enables the stack-protection to all
functions that declar

Add support for default stack-protector flag

The current stack-protector support is for none, "strong" or "all".
The default use of the flag enables the stack-protection to all
functions that declare a character array of eight bytes or more in
length on their stack.
This option can be tuned with the --param=ssp-buffer-size=N option.

Change-Id: I11ad9568187d58de1b962b8ae04edd1dc8578fb0
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>

show more ...

Merge pull request #925 from dp-arm/dp/spdx

Use SPDX license identifiers

Use SPDX license identifiers

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by

Use SPDX license identifiers

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by FreeBSD have not been modified.

[0]: https://spdx.org/

Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

show more ...

Merge pull request #886 from dp-arm/dp/stack-protector

Add support for GCC stack protection

Add support for GCC stack protection

Introduce new build option ENABLE_STACK_PROTECTOR. It enables
compilation of all BL images with one of the GCC -fstack-protector-*
options.

A new platform funct

Add support for GCC stack protection

Introduce new build option ENABLE_STACK_PROTECTOR. It enables
compilation of all BL images with one of the GCC -fstack-protector-*
options.

A new platform function plat_get_stack_protector_canary() is introduced.
It returns a value that is used to initialize the canary for stack
corruption detection. Returning a random value will prevent an attacker
from predicting the value and greatly increase the effectiveness of the
protection.

A message is printed at the ERROR level when a stack corruption is
detected.

To be effective, the global data must be stored at an address
lower than the base of the stacks. Failure to do so would allow an
attacker to overwrite the canary as part of an attack which would void
the protection.

FVP implementation of plat_get_stack_protector_canary is weak as
there is no real source of entropy on the FVP. It therefore relies on a
timer's value, which could be predictable.

Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

show more ...