- 20 Jun, 2018 1 commit
-
-
Soby Mathew authored
Currently TF-A doesn't initialise CNTFRQ register in CNTCTLBase frame of the system timer. ARM ARM states that "The instance of the register in the CNTCTLBase frame must be programmed with this value as part of system initialization." The psci_arch_setup() updates the CNTFRQ system register but according to the ARM ARM, this instance of the register is independent of the memory mapped instance. This is only an issue for Normal world software which relies on the memory mapped instance rather than the system register one. This patch resolves the issue for ARM platforms. The patch also solves a related issue on Juno, wherein CNTBaseN.CNTFRQ can be written and does not reflect the value of the register in CNTCTLBase frame. Hence this patch additionally updates CNTFRQ register in the Non Secure frame of the CNTBaseN. Fixes ARM-Software/tf-issues#593 Change-Id: I09cebb6633688b34d5b1bc349fbde4751025b350 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 19 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size reserved for BL2 has been increased. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 14 Jun, 2018 2 commits
-
-
Yann Gautier authored
When applying some MISRA rules, lots of issues are raised with BIT macro on AARCH32, and cast on uint32_t would be required (Rule 10.3). The macros BIT_32 and BIT_64 are then created for 32bit and 64bit. Then the BIT macro defaults on BIT_64 on AARCH64, and on BIT_32 on AARCH32. Signed-off-by: Yann Gautier <yann.gautier@st.com>
-
Yann Gautier authored
Import GENMASK_32 and GENMASK_64 macros from optee-os (permissive license). And default GENMASK is set to GENMASK_32 for AARCH32, and to GENMASK_64 for 64bit arch. fixes arm-software/tf-issues#596 Signed-off-by: Yann Gautier <yann.gautier@st.com> Signed-off-by: Nicolas Le Bayon <nicolas.le.bayon@st.com>
-
- 13 Jun, 2018 2 commits
-
-
Sandrine Bailleux authored
The translation tables allocated for the Secure Partition do not need to be treated as a special case. They can be put amongst the other tables mapping BL31's general purpose memory. They will be mapped with the same attributes as them, which is fine. The explicit alignment constraint in BL31's linker script to pad the last page of memory allocated to the Secure Partition's translation tables is useless too, as page tables are per se pages, thus their end address is naturally aligned on a page-boundary. In fact, this patch does not change the existing behaviour. Since patch 22282bb6 ("SPM: Move all SP-related info to SP context struct"), the secure_partition.c file has been renamed into sp_xlat.c but the linker script has not been properly updated. As a result, the SP translation tables are not specifically put at the start of the xlat_table linker section, the __SP_IMAGE_XLAT_TABLES_START__/_END__ symbols have the same value, the size of the resulting mmap_region covering these xlat tables is 0 and so it is ignored. Change-Id: I4cf0a4cc090298811cca53fc9cee74df0f2b1512 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Antonio Nino Diaz authored
The function xlat_arch_is_granule_size_supported() can be used to check if a specific granule size is supported. In Armv8, AArch32 only supports 4 KiB pages. AArch64 supports 4 KiB, 16 KiB or 64 KiB depending on the implementation, which is detected at runtime. The function xlat_arch_get_max_supported_granule_size() returns the max granule size supported by the implementation. Even though right now they are only used by SPM, they may be useful in other places in the future. This patch moves the code currently in SPM to the xlat tables lib so that it can be reused. Change-Id: If54624a5ecf20b9b9b7f38861b56383a03bbc8a4 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 12 Jun, 2018 2 commits
-
-
Daniel Boulby authored
Use a _ prefix for Macro arguments to prevent that argument from hiding variables of the same name in the outer scope Rule 5.3: An identifier declared in an inner scope shall not hide an identifier declared in an outer scope Fixed For: make LOG_LEVEL=50 PLAT=fvp Change-Id: I67b6b05cbad4aeca65ce52981b4679b340604708 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
Daniel Boulby authored
Conflict with function name and variable name within that function. Change the name of the function from image_size to get_image_size to remove conflict and make the function fit the normal project naming convention. Rule 5.3: An identifier declared in an inner scope shall not hide an identifier declared in an outer scope Fixed For: make LOG_LEVEL=50 PLAT=fvp Change-Id: I1a63d2730113e2741fffa79730459c584b0224d7 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 11 Jun, 2018 2 commits
-
-
Benjamin Fair authored
On TI platforms the UART is disabled by default and must be explicitly enabled using the MDR1 register. NOTE: The original definition of http://www.ti.com/lit/ds/symlink/pc16550d.pdf has no MDR register, but many TI SoCs implementing 16550 do have a quirky MDR register implemented. So, this should be enabled with TI_16550_MDR_QUIRK NOTE: In such implementation, the CSR register does not exist. Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com>
-
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 5 commits
-
-
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 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>
-
- 07 Jun, 2018 1 commit
-
-
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>
-
- 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 6 commits
-
-
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>
-
- 22 May, 2018 1 commit
-
-
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 1 commit
-
-
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>
-
- 18 May, 2018 3 commits
-
-
Soby Mathew authored
This patch implements support for adding dynamic configurations for BL31 (soc_fw_config), BL32 (tos_fw_config) and BL33 (nt_fw_config). The necessary cert tool support and changes to default chain of trust are made for these configs. Change-Id: I25f266277b5b5501a196d2f2f79639d838794518 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
This patch adds capability to FVP to disable authentication dynamically via the `disable_auth` property in TB_FW_CONFIG. Both BL1 and BL2 parses the TB_FW_CONFIG for the `disable_auth` property and invokes the `load_dyn_disable_auth()` API to disable authentication if the property is set to 1. The DYN_DISABLE_AUTH is enabled by default for FVP as it is a development platform. Note that the TB_FW_CONFIG has to be authenticated by BL1 irrespective of these settings. The arm_bl2_dyn_cfg_init() is now earlier in bl2_plat_preload_setup() rather than in bl2_platform_setup() as we need to get the value of `disable_auth` property prior to authentication of any image by BL2. Change-Id: I734acd59572849793e5020ec44c6ac51f654a4d1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
This patch allows platforms to dynamically disable authentication of images during cold boot. This capability is controlled via the DYN_DISABLE_AUTH build flag and is only meant for development purposes. Change-Id: Ia3df8f898824319bb76d5cc855b5ad6c3d227260 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 17 May, 2018 1 commit
-
-
Daniel Boulby authored
In 'console_set_scope' and when registering a console, field 'flags' of 'console_t' is assigned a 32-bit value. However, when it is actually used, the functions perform 64-bit reads to access its value. This patch changes all 64-bit reads to 32-bit reads. Change-Id: I181349371409e60065335f078857946fa3c32dc1 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 15 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
This reverts commit 2f18aa1f . It is causing some tests to fail. Until the cause is found and fixed, it is needed to remove this commit from master. Change-Id: Ic5ff7a841903a15613e00379e87cbbd8a0e85152 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 May, 2018 6 commits
-
-
Chris Kay authored
Change-Id: I7e73c0ab134da11c49f990b739245110c59eac2b Signed-off-by: Chris Kay <chris.kay@arm.com>
-
Chris Kay authored
SGI-575's NSRAM is neither in the same place nor the same size as Juno's. Change-Id: Id6d692e9c7e9c1360014bb525eda966ebe29c823 Signed-off-by: Chris Kay <chris.kay@arm.com>
-
Chris Kay authored
The bounds check in ARM_CASSERT_MMAP does not take into account the array sentinel in plat_arm_mmap. This commit fixes this, and adds an additional check to ensure the number of entries in the array is within the bounds of PLAT_ARM_MMAP_ENTRIES. Change-Id: Ie6df10c0aa0890d62826bc3224ad7b3e36fd53e2 Signed-off-by: Chris Kay <chris.kay@arm.com>
-
Chris Kay authored
There are three calls to mmap_add_region() that always occur in arm_setup_page_tables(), and two further calls based on whether coherent memory is enabled, and whether SPM is enabled in BL31. This commit adapts the ARM_BL_REGIONS definition to match the number of calls made inside arm_setup_page_tables() so that the MAX_MMAP_REGIONS is realigned with what is actually occurring. Change-Id: I7adc05951abccf2cbd5c86280eb874911e6a1566 Signed-off-by: Chris Kay <chris.kay@arm.com>
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size of BL31 has been increased in builds with SPM. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
In the multi console driver, allowing to register the same console more than once may result in an infinte loop when putc is called. If, for example, a boot message is trying to be printed, but the consoles in the loop in the linked list are runtime consoles, putc will iterate forever looking for a console that can print boot messages (or a NULL pointer that will never come). This loop in the linked list can occur after restoring the system from a system suspend. The boot console is registered during the cold boot in BL31, but the runtime console is registered even in the warm boot path. Consoles are always added to the start of the linked list when they are registered, so this it what should happen if they were actually different structures: console_list -> NULL console_list -> BOOT -> NULL console_list -> RUNTIME -> BOOT -> NULL console_list -> RUNTIME -> RUNTIME -> BOOT -> NULL In practice, the two runtime consoles are the same one, so they create this loop: console_list -> RUNTIME -. X -> BOOT -> NULL ^ | `----' This patch adds an assertion to detect this problem. The assertion will fail whenever the same structure tries to be registered while being on the list. In order to assert this, console_is_registered() has been implemented. It returns 1 if the specified console is registered, 0 if not. Change-Id: I922485e743775ca9bd1af9cbd491ddd360526a6d Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 09 May, 2018 1 commit
-
-
Roberto Vargas authored
When TF is compiled for aarch32 MAX_VIRT_ADDR_SPACE_SIZE is 2^32 in some cases, which makes the test (size) <= MAX_VIRT_ADDR_SPACE_SIZE a tautology because uintptr_t is a 32 bit value. The cast remove the warning for clang. Change-Id: I1345f3400f8fbbe4ffd3caa990a90e7ba593dba5 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 04 May, 2018 3 commits
-
-
Jeenu Viswambharan authored
- Assign 0x10 for RAS exceptions on ARM platforms, and install EHF priority descriptor. - Call the common RAS initialisation from ARM BL31 setup. - Add empty definitions for platform error records and RAS interrupts. Change-Id: I0675f299b7840be4c83a9c7a81073a95c605dc90 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
The ARMv8.4 RAS extensions introduce architectural support for software to inject faults into the system in order to test fault-handling software. This patch introduces the build option FAULT_HANDLING_SUPPORT to allow for lower ELs to use registers in the Standard Error Record to inject fault. The build option RAS_EXTENSIONS must also be enabled along with fault injection. This feature is intended for testing purposes only, and is advisable to keep disabled for production images. Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
EHF currently allows for registering interrupt handlers for a defined priority ranges. This is primarily targeted at various EL3 dispatchers to own ranges of secure interrupt priorities in order to delegate execution to lower ELs. The RAS support added by earlier patches necessitates registering handlers based on interrupt number so that error handling agents shall receive and handle specific Error Recovery or Fault Handling interrupts at EL3. This patch introduces a macro, RAS_INTERRUPTS() to declare an array of interrupt numbers and handlers. Error handling agents can use this macro to register handlers for individual RAS interrupts. The array is expected to be sorted in the increasing order of interrupt numbers. As part of RAS initialisation, the list of all RAS interrupts are sorted based on their ID so that, given an interrupt, its handler can be looked up with a simple binary search. For an error handling agent that wants to handle a RAS interrupt, platform must: - Define PLAT_RAS_PRI to be the priority of all RAS exceptions. - Enumerate interrupts to have the GIC driver program individual EL3 interrupts to the required priority range. This is required by EHF even before this patch. Documentation to follow. Change-Id: I9471e4887ff541f8a7a63309e9cd8f771f76aeda Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-