- 12 Jun, 2018 1 commit
-
-
Daniel Boulby authored
Rule 5.1: External identifiers shall be distinct Some of the identifier names in the GICv3 driver were so long that the first 31 characters were identical. This patch shortens these names to make sure they are different. Fixed for: LOG_LEVEL=50 PLAT=fvp Change-Id: Iecd551e3a015d144716b87b42c83dd3ab8c34d90 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 11 Jun, 2018 1 commit
-
-
Dimitris Papastamos authored
For the BL2_AT_EL3 configuration, move BL2 higher up to make more space for BL31. Adjust the BL31 limit to be up to BL2 base. This is because BL2 is always resident for the BL2_AT_EL3 configuration and thus we cannot overlay it with BL31. Change-Id: I71e89863ed48f5159e8b619f49c7c73b253397aa Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 08 Jun, 2018 12 commits
-
-
Dimitris Papastamos authored
Add support for Cortex-A76 and Cortex-Ares
-
Dimitris Papastamos authored
Revert "Code change to fix small bugs"
-
Dimitris Papastamos authored
-
Dimitris Papastamos authored
Fast path SMCCC_ARCH_WORKAROUND_1 calls from AArch32
-
Dimitris Papastamos authored
When dynamic mitigation is used, the SDEI handler is required to execute with the mitigation enabled by default, regardless of the mitigation state for lower ELs. This means that if the kernel or hypervisor explicitly disables the mitigation and then later when the event is dispatched, the dispatcher will remember the mitigation state for the lower ELs but force the mitigation to be on during the SDEI handler execution. When the SDEI handler returns, it will restore the mitigation state. This behaviour is described in "Firmware interfaces for mitigating cache speculation vulnerabilities System Software on Arm Systems"[0]. [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification Change-Id: I8dd60b736be0aa9e832b0f92d67a401fdeb417f4 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
The Cortex-A76 implements SMCCC_ARCH_WORKAROUND_2 as defined in "Firmware interfaces for mitigating cache speculation vulnerabilities System Software on Arm Systems"[0]. Dynamic mitigation for CVE-2018-3639 is enabled/disabled by setting/clearning bit 16 (Disable load pass store) of `CPUACTLR2_EL1`. NOTE: The generic code that implements dynamic mitigation does not currently implement the expected semantics when dispatching an SDEI event to a lower EL. This will be fixed in a separate patch. [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification Change-Id: I8fb2862b9ab24d55a0e9693e48e8be4df32afb5a Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
The upcoming patch that adds dynamic mitigation for Cortex-A76 requires that DYNAMIC_WORKAROUND_CVE_2018_3639=1. On FVP, we pull in all the CPU files into the build which means there will be a build failure if DYNAMIC_WORKAROUND_CVE_2018_3639=0. Change-Id: I2e781cbeafbf5d16eaabf76a1677e0c9f81269d2 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
The workaround uses the instruction patching feature of the Ares cpu. Change-Id: I868fce0dc0e8e41853dcce311f01ee3867aabb59 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Change-Id: Ia170c12d3929a616ba80eb7645c301066641f5cc Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Isla Mitchell authored
Both Cortex-Ares and Cortex-A76 CPUs use the ARM DynamIQ Shared Unit (DSU). The power-down and power-up sequences are therefore mostly managed in hardware, and required software operations are simple. Change-Id: I3a9447b5bdbdbc5ed845b20f6564d086516fa161 Signed-off-by: Isla Mitchell <isla.mitchell@arm.com>
-
Dimitris Papastamos authored
Code change to fix small bugs
-
Dimitris Papastamos authored
Juno: Bump up the BL1-RW size
-
- 07 Jun, 2018 5 commits
-
-
Soby Mathew authored
This patch bumps up the BL1-RW size for Juno and at the same time reduces the BL2 size when TBB is enabled, TF_MBEDTLS_KEY_ALG=rsa+ecdsa. The BL2 size for this config is reduced as it was observed that the peak memory usage is only reached when SPD=opteed and the dual rsa+ecdsa support is not needed for this case. Change-Id: Ia9009771b5cfd805e9cc75410aabb7db99fc2fbc Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Dimitris Papastamos authored
ARM platforms: Change memory layout and update documentation
-
Dimitris Papastamos authored
When SMCCC_ARCH_WORKAROUND_1 is invoked from a lower EL running in AArch32 state, ensure that the SMC call will take a shortcut in EL3. This minimizes the time it takes to apply the mitigation in EL3. When lower ELs run in AArch32, it is preferred that they execute the `BPIALL` instruction to invalidate the BTB. However, on some cores the `BPIALL` instruction may be a no-op and thus would benefit from making the SMCCC_ARCH_WORKAROUND_1 call go through the fast path. Change-Id: Ia38abd92efe2c4b4a8efa7b70f260e43c5bda8a5 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Soby Mathew authored
This patch updates the firmware design guide for the BL memory layout change on ARM platforms. Change-Id: Icbfe7249484bb8b4ba3c94421172d42f27605c52 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
The patch changes the layout of BL images in memory to enable more efficient use of available space. Previously BL31 was loaded with the expectation that BL2 memory would be reclaimed by BL32 loaded in SRAM. But with increasing memory requirements in the firmware, we can no longer fit BL32 in SRAM anymore which means the BL2 memory is not reclaimed by any runtime image. Positioning BL2 below BL1-RW and above BL31 means that the BL31 NOBITS can be overlaid on BL2 and BL1-RW. This patch also propogates the same memory layout to BL32 for AArch32 mode. The reset addresses for the following configurations are also changed : * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode * When BL2_AT_EL3=1 for BL2 The restriction on BL31 to be only in DRAM when SPM is enabled is now removed with this change. The update to the firmware design guide for the BL memory layout is done in the following patch. Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 29 May, 2018 1 commit
-
-
Dimitris Papastamos authored
Implement workaround for CVE-2018-3639 on Cortex A57/A72/A73 and A75
-
- 25 May, 2018 3 commits
-
-
Daniel Boulby authored
A pointer to rt_svc_desc_t was defined both in the function and globally. The innermost definition hid the global definition which is the one we want to use so remove the innermost definition to prevent this Change-Id: Idabdbc0947178ae83224bd17a9b170df7c278d51 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
Daniel Boulby authored
The weak pragma was assigned twice to the bl2_plat_handle_post_image_load definition both in plat/common/ and in plat/arm/common/ this was an error as it should have only have been defined in plat/common Change-Id: Id85e14c699cb09ed998d1677f2a172e760911918 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
Dimitris Papastamos authored
SPM: Refactor codebase
-
- 24 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
BL31 is running out of space, and the use-case of SPM doesn't require it to be in SRAM. To prevent BL31 from running out of space in the future, move BL31 to DRAM if SPM is enabled. Secure Partition Manager design document updated to reflect the changes. Increased the size of the stack of BL31 for builds with SPM. The translation tables used by SPM in Arm platforms have been moved back to the 'xlat_tables' region instead of 'arm_el3_tzc_dram'. Everything is in DRAM now, so it doesn't make sense to treat them in a different way. Change-Id: Ia6136c8e108b8da9edd90e9d72763dada5e5e5dc Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 May, 2018 11 commits
-
-
Antonio Nino Diaz authored
Simplify the code of the SMC handler by extracting the code of SP_EVENT_COMPLETE and MM_COMMUNICATE. Change-Id: I9250a3f5e4b807b35c9d044592c1074a45ab9a07 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Instead of just knowing if the Secure Partition is being initialized or not, this generic state enum can be used to tell if the Secure Partition is busy and to add more states in the future if needed. Also, the spinlock of the secure_partition_context_t structure now only protects against concurrent accesses to the state of the secure partition. Previously, it used to lock down the whole structure, thus preventing one CPU to access any of its fields while another CPU was executing the partition. Change-Id: I51215328e2ca8ea2452f92e4a1cb237415958b22 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
The current internal names are too long, which makes it hard to write code as many lines overflow the limit and need to be split, which may not help the reader. Change-Id: I072bdc8f3dd125255063ffa7f02500e5228fc9a1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
This is done in order to make it easier to read the file spm_main.c. Change-Id: I21e765154c1682a319a3bc47a19a42fd736e910e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Move all information related to a Secure Partition to the struct secure_partition_context_t. This requires an in-depth refactor because most of the previous code of SPM relied on global information. Change-Id: I0a23e93817dcc191ce1d7506b8bc671d376123c4 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
This function can be currently accessed through the wrappers cm_init_context_by_index() and cm_init_my_context(). However, they only work on contexts that are associated to a CPU. By making this function public, it is possible to set up a context that isn't associated to any CPU. For consistency, it has been renamed to cm_setup_context(). Change-Id: Ib2146105abc8137bab08745a8adb30ca2c4cedf4 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Dimitris Papastamos authored
Some CPUS may benefit from using a dynamic mitigation approach for CVE-2018-3639. A new SMC interface is defined to allow software executing in lower ELs to enable or disable the mitigation for their execution context. It should be noted that regardless of the state of the mitigation for lower ELs, code executing in EL3 is always mitigated against CVE-2018-3639. NOTE: This change is a compatibility break for any platform using the declare_cpu_ops_workaround_cve_2017_5715 macro. Migrate to the declare_cpu_ops_wa macro instead. Change-Id: I3509a9337ad217bbd96de9f380c4ff8bf7917013 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Implement static mitigation for CVE-2018-3639 on Cortex A57 and A72. Change-Id: I83409a16238729b84142b19e258c23737cc1ddc3 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
For affected CPUs, this approach enables the mitigation during EL3 initialization, following every PE reset. No mechanism is provided to disable the mitigation at runtime. This approach permanently mitigates the entire software stack and no additional mitigation code is required in other software components. TF-A implements this approach for the following affected CPUs: * Cortex-A57 and Cortex-A72, by setting bit 55 (Disable load pass store) of `CPUACTLR_EL1` (`S3_1_C15_C2_0`). * Cortex-A73, by setting bit 3 of `S3_0_C15_C0_0` (not documented in the Technical Reference Manual (TRM)). * Cortex-A75, by setting bit 35 (reserved in TRM) of `CPUACTLR_EL1` (`S3_0_C15_C1_0`). Additionally, a new SMC interface is implemented to allow software executing in lower ELs to discover whether the system is mitigated against CVE-2018-3639. Refer to "Firmware interfaces for mitigating cache speculation vulnerabilities System Software on Arm Systems"[0] for more information. [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification Change-Id: I084aa7c3bc7c26bf2df2248301270f77bed22ceb Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
This patch renames symbols and files relating to CVE-2017-5715 to make it easier to introduce new symbols and files for new CVE mitigations. Change-Id: I24c23822862ca73648c772885f1690bed043dbc7 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Extend dynamic configuration
-
- 22 May, 2018 3 commits
-
-
Dimitris Papastamos authored
Correct some typo errors in comment
-
Dimitris Papastamos authored
Remove the DTBs and update userguide for FVP
-
Qixiang Xu authored
File: include/common/aarch64/el3_common_macros.S Change-Id: I619401e961a3f627ad8864781b5f90bc747c3ddb Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
-
- 21 May, 2018 2 commits
-
-
Dimitris Papastamos authored
Ensure read and write of flags defined in the console struct are 32 bit
-
Soby Mathew authored
This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-