Tree:
e6d2aea159
dependabot/npm_and_yarn/word-wrap-1.2.4
dependabot/pip/docs/markdown-it-py-2.2.0
dependabot/pip/requests-2.31.0
dependabot/pip/urllib3-2.0.6
master
arm_cca_v0.1
arm_cca_v0.2
arm_cca_v0.3
for-v0.4-rc0
for-v0.4/05.20
for-v0.4/05.21
for-v0.4/05.22
lts-test
lts-v2.10.1
lts-v2.10.2
lts-v2.10.3
lts-v2.10.4
lts-v2.8-rc0
lts-v2.8.0
lts-v2.8.1
lts-v2.8.10
lts-v2.8.11
lts-v2.8.12
lts-v2.8.13
lts-v2.8.14
lts-v2.8.15
lts-v2.8.16
lts-v2.8.17
lts-v2.8.18
lts-v2.8.2
lts-v2.8.3
lts-v2.8.4
lts-v2.8.5
lts-v2.8.6
lts-v2.8.7
lts-v2.8.8
lts-v2.8.9
sandbox/lts-v2.10.3-20240319T0822
sandbox/lts-v2.10.3-20240319T1236
sandbox/lts-v2.10.3-20240404T0850
sandbox/lts-v2.10.3-20240405T0714
sandbox/lts-v2.10.3-test1
v0.2
v0.3
v0.3-Juno
v0.3-Juno-0.2
v0.3-Juno-0.3
v0.4
v0.4-Juno-0.4
v0.4-Juno-0.4-rc0
v0.4-Juno-0.5
v0.4-Juno-0.5-rc0
v0.4-Juno-0.5-rc1
v0.4-Juno-0.6-rc0
v0.4-Juno-0.6-rc1
v0.4-rc1
v0.4-rc2
v1.0
v1.0-rc0
v1.1
v1.1-Juno-0.1
v1.1-rc0
v1.1-rc1
v1.1-rc2
v1.1-rc3
v1.2
v1.2-rc0
v1.3
v1.3-rc0
v1.3_rc1
v1.3_rc2
v1.4
v1.4-rc0
v1.5
v1.5-rc0
v1.5-rc1
v1.5-rc2
v1.5-rc3
v1.6
v1.6-rc0
v1.6-rc1
v2.0
v2.0-rc0
v2.1
v2.1-rc0
v2.1-rc1
v2.10
v2.10-rc0
v2.10-rc1
v2.10.0
v2.2
v2.2-rc0
v2.2-rc1
v2.2-rc2
v2.3
v2.3-rc0
v2.3-rc1
v2.3-rc2
v2.4
v2.4-rc0
v2.4-rc1
v2.4-rc2
v2.5
v2.5-rc0
v2.5-rc1
v2.6
v2.6-rc0
v2.6-rc1
v2.7
v2.7-rc0
v2.7-rc1
v2.7.0
v2.8
v2.8-rc0
v2.8.0
v2.9
v2.9-rc0
v2.9-rc1
v2.9.0
${ noResults }
7 Commits (e6d2aea159f4b88fc128ae62432c8fff4b0c2e5f)
Author | SHA1 | Message | Date |
---|---|---|---|
Douglas Raillard | 51faada71a |
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> |
8 years ago |
dp-arm | 75311203d8 |
Move plat/common source file definitions to generic Makefiles
These source file definitions should be defined in generic Makefiles so that all platforms can benefit. Ensure that the symbols are properly marked as weak so they can be overridden by platforms. NOTE: This change is a potential compatibility break for non-upstream platforms. Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed Signed-off-by: dp-arm <dimitris.papastamos@arm.com> |
8 years ago |
Douglas Raillard | 308d359b26 |
Introduce unified API to zero memory
Introduce zeromem_dczva function on AArch64 that can handle unaligned addresses and make use of DC ZVA instruction to zero a whole block at a time. This zeroing takes place directly in the cache to speed it up without doing external memory access. Remove the zeromem16 function on AArch64 and replace it with an alias to zeromem. This zeromem16 function is now deprecated. Remove the 16-bytes alignment constraint on __BSS_START__ in firmware-design.md as it is now not mandatory anymore (it used to comply with zeromem16 requirements). Change the 16-bytes alignment constraints in SP min's linker script to a 8-bytes alignment constraint as the AArch32 zeromem implementation is now more efficient on 8-bytes aligned addresses. Introduce zero_normalmem and zeromem helpers in platform agnostic header that are implemented this way: * AArch32: * zero_normalmem: zero using usual data access * zeromem: alias for zero_normalmem * AArch64: * zero_normalmem: zero normal memory using DC ZVA instruction (needs MMU enabled) * zeromem: zero using usual data access Usage guidelines: in most cases, zero_normalmem should be preferred. There are 2 scenarios where zeromem (or memset) must be used instead: * Code that must run with MMU disabled (which means all memory is considered device memory for data accesses). * Code that fills device memory with null bytes. Optionally, the following rule can be applied if performance is important: * Code zeroing small areas (few bytes) that are not secrets should use memset to take advantage of compiler optimizations. Note: Code zeroing security-related critical information should use zero_normalmem/zeromem instead of memset to avoid removal by compilers' optimizations in some cases or misbehaving versions of GCC. Fixes ARM-software/tf-issues#408 Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com> |
8 years ago |
Jeenu Viswambharan | a806dad58c |
Define and use no_ret macro where no return is expected
There are many instances in ARM Trusted Firmware where control is transferred to functions from which return isn't expected. Such jumps are made using 'bl' instruction to provide the callee with the location from which it was jumped to. Additionally, debuggers infer the caller by examining where 'lr' register points to. If a 'bl' of the nature described above falls at the end of an assembly function, 'lr' will be left pointing to a location outside of the function range. This misleads the debugger back trace. This patch defines a 'no_ret' macro to be used when jumping to functions from which return isn't expected. The macro ensures to use 'bl' instruction for the jump, and also, for debug builds, places a 'nop' instruction immediately thereafter (unless instructed otherwise) so as to leave 'lr' pointing within the function range. Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0 Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
8 years ago |
Sandrine Bailleux | 5d1c104f9a |
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start with their code section, followed by their read-only data section. The two sections are contiguous in memory. Therefore, the end of the code section and the beginning of the read-only data one might share a memory page. This forces both to be mapped with the same memory attributes. As the code needs to be executable, this means that the read-only data stored on the same memory page as the code are executable as well. This could potentially be exploited as part of a security attack. This patch introduces a new build flag called SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data on separate memory pages. This in turn allows independent control of the access permissions for the code and read-only data. This has an impact on memory footprint, as padding bytes need to be introduced between the code and read-only data to ensure the segragation of the two. To limit the memory cost, the memory layout of the read-only section has been changed in this case. - When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e. the read-only section still looks like this (padding omitted): | ... | +-------------------+ | Exception vectors | +-------------------+ | Read-only data | +-------------------+ | Code | +-------------------+ BLx_BASE In this case, the linker script provides the limits of the whole read-only section. - When SEPARATE_CODE_AND_RODATA=1, the exception vectors and read-only data are swapped, such that the code and exception vectors are contiguous, followed by the read-only data. This gives the following new layout (padding omitted): | ... | +-------------------+ | Read-only data | +-------------------+ | Exception vectors | +-------------------+ | Code | +-------------------+ BLx_BASE In this case, the linker script now exports 2 sets of addresses instead: the limits of the code and the limits of the read-only data. Refer to the Firmware Design guide for more details. This provides platform code with a finer-grained view of the image layout and allows it to map these 2 regions with the appropriate access permissions. Note that SEPARATE_CODE_AND_RODATA applies to all BL images. Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49 |
8 years ago |
Antonio Nino Diaz | 1c3ea103d2 |
Remove all non-configurable dead loops
Added a new platform porting function plat_panic_handler, to allow platforms to handle unexpected error situations. It must be implemented in assembly as it may be called before the C environment is initialized. A default implementation is provided, which simply spins. Corrected all dead loops in generic code to call this function instead. This includes the dead loop that occurs at the end of the call to panic(). All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have been removed. Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134 |
9 years ago |
Yatharth Kochar | 9003fa0b0c |
FWU: Add Generic BL2U FWU image support in BL2
The Firmware Update (FWU) feature needs support for an optional secure world image, BL2U, to allow additional secure world initialization required by FWU, for example DDR initialization. This patch adds generic framework support to create BL2U. NOTE: A platform makefile must supply additional `BL2U_SOURCES` to build the bl2u target. A subsequent patch adds bl2u support for ARM platforms. Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413 |
9 years ago |