summaryrefslogtreecommitdiff
path: root/include/common/aarch32
AgeCommit message (Collapse)Author
2018-01-25Merge pull request #1228 from dp-arm/dp/cve_2017_5715davidcunado-arm
Workarounds for CVE-2017-5715 on A9/A15 and A17 + serial console reporting
2018-01-18sp_min: Implement workaround for CVE-2017-5715Dimitris Papastamos
This patch introduces two workarounds for ARMv7 systems. The workarounds need to be applied prior to any `branch` instruction in secure world. This is achieved using a custom vector table where each entry is an `add sp, sp, #1` instruction. On entry to monitor mode, once the sequence of `ADD` instructions is executed, the branch target buffer (BTB) is invalidated. The bottom bits of `SP` are then used to decode the exception entry type. A side effect of this change is that the exception vectors are installed before the CPU specific reset function. This is now consistent with how it is done on AArch64. Note, on AArch32 systems, the exception vectors are typically tightly integrated with the secure payload (e.g. the Trusted OS). This workaround will need porting to each secure payload that requires it. The patch to modify the AArch32 per-cpu vbar to the corresponding workaround vector table according to the CPU type will be done in a later patch. Change-Id: I5786872497d359e496ebe0757e8017fa98f753fa Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2018-01-18bl2-el3: Add BL2_EL3 imageRoberto Vargas
This patch enables BL2 to execute at the highest exception level without any dependancy on TF BL1. This enables platforms which already have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL stages without need for BL1. This is not currently possible because BL2 executes at S-EL1 and cannot jump straight to EL3. Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2017-11-08ARMv7 may not support Virtualization ExtensionsEtienne Carriere
ARMv7-A Virtualization extensions brings new instructions and resources that were supported by later architectures. Reference ARM ARM Issue C.c [DDI0406C_C]. ERET and extended MSR/MRS instructions, as specified in [DDI0406C_C] in ID_PFR1 description of bits[15:12] (Virtualization Extensions): A value of 0b0001 implies implementation of the HVC, ERET, MRS (Banked register), and MSR (Banked register) instructions. The ID_ISARs do not identify whether these instructions are implemented. UDIV/SDIV were introduced with the Virtualization extensions, even if not strictly related to the virtualization extensions. If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_VIRTUALIZATION to enable virtualization extension related resources. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2017-11-08ARMv7 does not support SDCREtienne Carriere
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2017-11-08ARMv7 does not support STL instructionEtienne Carriere
Also need to add a SEV instruction in ARMv7 spin_unlock which is implicit in ARMv8. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2017-09-01cpu log buffer size depends on cache line sizeEtienne Carriere
Platform may use specific cache line sizes. Since CACHE_WRITEBACK_GRANULE defines the platform specific cache line size, it is used to define the size of the cpu data structure CPU_DATA_SIZE aligned on cache line size. Introduce assembly macro 'mov_imm' for AArch32 to simplify implementation of function '_cpu_data_by_index'. Change-Id: Ic2d49ffe0c3e51649425fd9c8c99559c582ac5a1 Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2017-06-21Fully initialise essential control registersDavid Cunado
This patch updates the el3_arch_init_common macro so that it fully initialises essential control registers rather then relying on hardware to set the reset values. The context management functions are also updated to fully initialise the appropriate control registers when initialising the non-secure and secure context structures and when preparing to leave EL3 for a lower EL. This gives better alignement with the ARM ARM which states that software must initialise RES0 and RES1 fields with 0 / 1. This patch also corrects the following typos: "NASCR definitions" -> "NSACR definitions" Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc Signed-off-by: David Cunado <david.cunado@arm.com>
2017-05-03Use SPDX license identifiersdp-arm
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>
2017-04-21Merge pull request #910 from dp-arm/dp/AArch32-juno-portdavidcunado-arm
Add AArch32 support for Juno
2017-04-20AArch32: Add support for ARM Cortex-A53/57/72 MPCore ProcessorYatharth Kochar
This patch adds AArch32 state support for ARM Cortex-A53, Cortex-A57 and Cortex-A72 MPCore Processor in the CPU specific operations framework. NOTE: CPU errata handling code is not present in this patch. Change-Id: I01eb3e028e40dde37565707ebc99e06e7a0c113d Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-04-20Remove build option `ASM_ASSERTION`Antonio Nino Diaz
The build option `ENABLE_ASSERTIONS` should be used instead. That way both C and ASM assertions can be enabled or disabled together. All occurrences of `ASM_ASSERTION` in common code and ARM platforms have been replaced by `ENABLE_ASSERTIONS`. ASM_ASSERTION has been removed from the user guide. Change-Id: I51f1991f11b9b7ff83e787c9a3270c274748ec6f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-03-31Add support for GCC stack protectionDouglas Raillard
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>
2017-02-15Disable secure self-hosted debug via MDCR_EL3/SDCRdp-arm
Trusted Firmware currently has no support for secure self-hosted debug. To avoid unexpected exceptions, disable software debug exceptions, other than software breakpoint instruction exceptions, from all exception levels in secure state. This applies to both AArch32 and AArch64 EL3 initialization. Change-Id: Id097e54a6bbcd0ca6a2be930df5d860d8d09e777 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-01-30Allow spin locks to be defined from assemblyJeenu Viswambharan
At present, spin locks can only defined from C files. Add some macros such that they can be defined from assembly files too. Change-Id: I64f0c214062f5c15b3c8b412c7f25c908e87d970 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-01-24Use #ifdef for IMAGE_BL* instead of #ifMasahiro Yamada
One nasty part of ATF is some of boolean macros are always defined as 1 or 0, and the rest of them are only defined under certain conditions. For the former group, "#if FOO" or "#if !FOO" must be used because "#ifdef FOO" is always true. (Options passed by $(call add_define,) are the cases.) For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because checking the value of an undefined macro is strange. Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like follows: $(eval IMAGE := IMAGE_BL$(call uppercase,$(3))) $(OBJ): $(2) @echo " CC $$<" $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@ This means, IMAGE_BL* is defined when building the corresponding image, but *undefined* for the other images. So, IMAGE_BL* belongs to the latter group where we should use #ifdef or #ifndef. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-12-19AArch32: Print ASM_ASSERT and panic messagesJeenu Viswambharan
ASM_ASSERT failure and panic messages are suppressed at present. This patch enables printing the PC location for panic messages, and file name and line number upon assembly assert failure. Change-Id: I80cb715988e7ce766f64da1e1d7065a74a096a0c Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2016-12-12Merge pull request #774 from jeenu-arm/no-return-macrodanh-arm
Define and use no_ret macro where no return is expected
2016-12-05Define and use no_ret macro where no return is expectedJeenu Viswambharan
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>
2016-12-01Reset EL2 and EL3 configurable controlsDavid Cunado
This patch resets EL2 and EL3 registers that have architecturally UNKNOWN values on reset and that also provide EL2/EL3 configuration and trap controls. Specifically, the EL2 physical timer is disabled to prevent timer interrups into EL2 - CNTHP_CTL_EL2 and CNTHP_CTL for AArch64 and AArch32, respectively. Additionally, for AArch64, HSTR_EL2 is reset to avoid unexpected traps of non-secure access to certain system registers at EL1 or lower. For AArch32, the patch also reverts the reset to SDCR which was incorrectly added in a previous change. Change-Id: If00eaa23afa7dd36a922265194ccd6223187414f Signed-off-by: David Cunado <david.cunado@arm.com>
2016-11-09Reset debug registers MDCR-EL3/SDCR and MDCR_EL2/HDCRDavid Cunado
In order to avoid unexpected traps into EL3/MON mode, this patch resets the debug registers, MDCR_EL3 and MDCR_EL2 for AArch64, and SDCR and HDCR for AArch32. MDCR_EL3/SDCR is zero'ed when EL3/MON mode is entered, at the start of BL1 and BL31/SMP_MIN. For MDCR_EL2/HDCR, this patch zero's the bits that are architecturally UNKNOWN values on reset. This is done when exiting from EL3/MON mode but only on platforms that support EL2/HYP mode but choose to exit to EL1/SVC mode. Fixes ARM-software/tf-issues#430 Change-Id: Idb992232163c072faa08892251b5626ae4c3a5b6 Signed-off-by: David Cunado <david.cunado@arm.com>
2016-09-28AArch32: Add `memcpy4` function in assemblyYatharth Kochar
At present the `el3_entrypoint_common` macro uses `memcpy` function defined in lib/stdlib/mem.c file, to copy data from ROM to RAM for BL1. Depending on the compiler being used the stack could potentially be used, in `memcpy`, for storing the local variables. Since the stack is initialized much later in `el3_entrypoint_common` it may result in unknown behaviour. This patch adds `memcpy4` function definition in assembly so that it can be used before the stack is initialized and it also replaces `memcpy` by `memcpy4` in `el3_entrypoint_common` macro, to copy data from ROM to RAM for BL1. Change-Id: I3357a0e8095f05f71bbbf0b185585d9499bfd5e0
2016-09-21AArch32: Common changes needed for BL1/BL2Yatharth Kochar
This patch adds common changes to support AArch32 state in BL1 and BL2. Following are the changes: * Added functions for disabling MMU from Secure state. * Added AArch32 specific SMC function. * Added semihosting support. * Added reporting of unhandled exceptions. * Added uniprocessor stack support. * Added `el3_entrypoint_common` macro that can be shared by BL1 and BL32 (SP_MIN) BL stages. The `el3_entrypoint_common` is similar to the AArch64 counterpart with the main difference in the assembly instructions and the registers that are relevant to AArch32 execution state. * Enabled `LOAD_IMAGE_V2` flag in Makefile for `ARCH=aarch32` and added check to make sure that platform has not overridden to disable it. Change-Id: I33c6d8dfefb2e5d142fdfd06a0f4a7332962e1a3
2016-08-10AArch32: Add assembly helpersSoby Mathew
This patch adds various assembly helpers for AArch32 like : * cache management : Functions to flush, invalidate and clean cache by MVA. Also helpers to do cache operations by set-way are also added. * stack management: Macros to declare stack and get the current stack corresponding to current CPU. * Misc: Macros to access co processor registers in AArch32, macros to define functions in assembly, assert macros, generic `do_panic()` implementation and function to zero block of memory. Change-Id: I7b78ca3f922c0eda39beb9786b7150e9193425be