feat(build): pass cflags to the linker when LTO is enabledUsually, both compiling and linking happen by calling the top levelgcc/clang binary. Also, both compilers quite specifically tell us topa
feat(build): pass cflags to the linker when LTO is enabledUsually, both compiling and linking happen by calling the top levelgcc/clang binary. Also, both compilers quite specifically tell us topass the same flags to the compilation and linking stages when we enableLTO. This is crucial for things like the undefined behaviour sanitiser.Anecdotally, in working on this, there have been a fair few errors thatthe compiler has only been able to catch due to warning flags beingpassed to the linker and building with LTO.This patch puts the contents of TF_CFLAGS into TF_LDFLAGS when LTO isenabled. This is easier said than done, however, as we support buildingwith clang and linking with gcc (or vice versa), so CFLAGS that arediscovered for one will not work for the other. This patch works aroundthis by splitting all flags into a per-compiler variable. Then CFLAGSand LDFLAGS get the contents of the correct one.Some notable side effects: CPPFLAGS and TF_CFLAGS_$(ARCH) become emptyand 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 forconsistency. This is because they currently don't work with LTO and willbe addressed in a later patch.Finally, ERROR_DEPRECATED's flags are also identical on all compilers sodon't maintain a difference.Change-Id: I3630729ee5f474c09d4722cd0ede6845e1725d95Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
chore: update to use Arm word across TF-AAlign entire TF-A to use Arm in copyright header.Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244Signed-off-by: Govindraj Raja <govindraj.raja@arm.co
chore: update to use Arm word across TF-AAlign entire TF-A to use Arm in copyright header.Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Disable stack protection explicitlyExplicitly disable stack protection via the "-fno-stack-protector"compiler option when the ENABLE_STACK_PROTECTOR build option isset to "none" (the default).T
Disable stack protection explicitlyExplicitly disable stack protection via the "-fno-stack-protector"compiler option when the ENABLE_STACK_PROTECTOR build option isset to "none" (the default).This allows the build to complete without link errors on systems wherestack protection is enabled by default in the compiler.Change-Id: I0a676aa672815235894fb2cd05fa2b196fabb972Signed-off-by: Simon South <simon@simonsouth.net>
Add support for default stack-protector flagThe current stack-protector support is for none, "strong" or "all".The default use of the flag enables the stack-protection to allfunctions that declar
Add support for default stack-protector flagThe current stack-protector support is for none, "strong" or "all".The default use of the flag enables the stack-protection to allfunctions that declare a character array of eight bytes or more inlength on their stack.This option can be tuned with the --param=ssp-buffer-size=N option.Change-Id: I11ad9568187d58de1b962b8ae04edd1dc8578fb0Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Sanitise includes across codebaseEnforce 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 codebaseEnforce 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 forincludes isn't a good idea. It defeats one of the advantages of havingfolders and it introduces problems that are sometimes subtle (becauseyou may not know the header you are actually including if there are twoof them).For example, this patch had to be created because two headers werecalled the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platformto avoid collision."). More recently, this patch has had similarproblems: 46f9b2c3a282 ("drivers: add tzc380 support").This problem was introduced in commit 4ecca33988b9 ("Move include andsource files to logical locations"). At that time, there weren't toomany headers so it wasn't a real issue. However, time has shown thatthis creates problems.Platforms that want to preserve the way they include headers may add theremoved paths to PLAT_INCLUDES, but this is discouraged.Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8fSigned-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Use SPDX license identifiersTo make software license auditing simpler, use SPDX[0] licenseidentifiers instead of duplicating the license text in every file.NOTE: Files that have been imported by
Use SPDX license identifiersTo make software license auditing simpler, use SPDX[0] licenseidentifiers 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: I80a00e1f641b8cc075ca5a95b10607ed9ed8761aSigned-off-by: dp-arm <dimitris.papastamos@arm.com>
Add support for GCC stack protectionIntroduce new build option ENABLE_STACK_PROTECTOR. It enablescompilation of all BL images with one of the GCC -fstack-protector-*options.A new platform funct
Add support for GCC stack protectionIntroduce new build option ENABLE_STACK_PROTECTOR. It enablescompilation 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 stackcorruption detection. Returning a random value will prevent an attackerfrom predicting the value and greatly increase the effectiveness of theprotection.A message is printed at the ERROR level when a stack corruption isdetected.To be effective, the global data must be stored at an addresslower than the base of the stacks. Failure to do so would allow anattacker to overwrite the canary as part of an attack which would voidthe protection.FVP implementation of plat_get_stack_protector_canary is weak asthere is no real source of entropy on the FVP. It therefore relies on atimer's value, which could be predictable.Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>