- 03 Jul, 2018 1 commit
-
-
Antonio Nino Diaz authored
Instead of having one big file with all the code, it's better to have a few smaller files that are more manageable: - xlat_tables_core.c: Code related to the core functionality of the library (map and unmap regions, initialize xlat context). - xlat_tables_context.c: Instantiation of the active image context as well as APIs to manipulate it. - xlat_tables_utils.c: Helper code that isn't part of the core functionality (change attributes, debug print messages). Change-Id: I3ea956fc1afd7473c0bb5e7c6aab3b2e5d88c711 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 27 Jun, 2018 1 commit
-
-
Jeenu Viswambharan authored
At present, the function provided by the translation library to enable MMU constructs appropriate values for translation library, and programs them to the right registers. The construction of initial values, however, is only required once as both the primary and secondaries program the same values. Additionally, the MMU-enabling function is written in C, which means there's an active stack at the time of enabling MMU. On some systems, like Arm DynamIQ, having active stack while enabling MMU during warm boot might lead to coherency problems. This patch addresses both the above problems by: - Splitting the MMU-enabling function into two: one that sets up values to be programmed into the registers, and another one that takes the pre-computed values and writes to the appropriate registers. With this, the primary effectively calls both functions to have the MMU enabled, but secondaries only need to call the latter. - Rewriting the function that enables MMU in assembly so that it doesn't use stack. This patch fixes a bunch of MISRA issues on the way. Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 26 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The meaning of them wasn't clear in the header file, it was needed to search the code for the places where they are used. Add parentheses to macros in the same header. Change-Id: I700bc0fd75ccfc0a34f439cb3b2692861bb73b9b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 Jun, 2018 1 commit
-
-
Nariman Poushin authored
This is to fix a number of Coverity Scan DEADCODE defects, CID numbers listed below, as reported from https://scan.coverity.com/projects/arm-software-arm-trusted-firmware CID 267023 CID 267022 CID 267020 Change-Id: I2963a799b210149e84ccab5c5b9082267ddfe337 Signed-off-by: Nariman Poushin <nariman.poushin@linaro.org>
-
- 22 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The values defined in this type are used in logical operations, which goes against MISRA Rule 10.1: "Operands shall not be of an inappropriate essential type". Now, `unsigned int` is used instead. This also allows us to move the dynamic mapping bit from 30 to 31. It was an undefined behaviour in the past because an enum is signed by default, and bit 31 corresponds to the sign bit. It is undefined behaviour to modify the sign bit. Now, bit 31 is free to use as it was originally meant to be. mmap_attr_t is now defined as an `unsigned int` for backwards compatibility. Change-Id: I6b31218c14b9c7fdabebe432de7fae6e90a97f34 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 21 Jun, 2018 4 commits
-
-
Jeenu Viswambharan authored
SDEI event dispatches currently only sets up the Non-secure context before returning to the caller. The actual dispatch only happens upon exiting EL3 next time. However, for various error handling scenarios, it's beneficial to have the dispatch happen synchronously. I.e. when receiving SDEI interrupt, or for a successful sdei_dispatch_event() call, the event handler is executed; and upon the event completion, dispatcher execution resumes after the point of dispatch. The jump primitives introduced in the earlier patch facilitates this feature. With this patch: - SDEI interrupts and calls to sdei_dispatch_event prepares the NS context for event dispatch, then sets a jump point, and immediately exits EL3. This results in the client handler executing in Non-secure. - When the SDEI client completes the dispatched event, the SDEI dispatcher does a longjmp to the jump pointer created earlier. For the caller of the sdei_dispatch_event() in particular, this would appear as if call returned successfully. The dynamic workaround for CVE_2018_3639 is slightly shifted around as part of related minor refactoring. It doesn't affect the workaround functionality. Documentation updated. NOTE: This breaks the semantics of the explicit dispatch API, and any exiting usages should be carefully reviewed. Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
This patch introduces setjmp() and ongjmp() primitives to enable standard setjmp/longjmp style execution. Both APIs parameters take a pointer to struct jmpbuf type, which hosts CPU registers saved/restored during jump. As per the standard usage: - setjmp() return 0 when a jump is setup; and a non-zero value when returning from jump. - The caller of setjmp() must not return, or otherwise update stack pointer since. Change-Id: I4af1d32e490cfa547979631b762b4cba188d0551 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
The current macros only allow to define dynamic and statically-bound SDEI events. However, there ought be a mechanism to define SDEI events that are explicitly dispatched; i.e., events that are dispatched as a result of a previous secure interrupt or other exception This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit event. They must be placed under private mappings. Only the priority flags are allowed to be additionally specified. Documentation updated. Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Dimitris Papastamos authored
Change-Id: I67e64bb79cc984ea3263f069e22738a42321c46d Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 20 Jun, 2018 2 commits
-
-
Antonio Nino Diaz authored
It may be needed to enter the Secure Partition through other means than an MM_COMMUNICATE SMC. This patch enables this behaviour by extracting the necessary code from mm_communicate() and allowing other parts of the code to use it. Change-Id: I59f6638d22d9c9d0baff0984f39d056298a8dc8e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
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>
-
- 18 Jun, 2018 1 commit
-
-
Roberto Vargas authored
Having these definitions in board_arm_def.h forces to all the arm platforms to use the same definition for PLAT_ARM_MEM_PROT_ADDR. This macro also enables the mem-protect mechanism, which means that all the arm platform has enabled mem-protect and they cannot get rid of it. Change-Id: Id29d2c51cbe6edc15f010a9f5a20c42266c48a08 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 14 Jun, 2018 3 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>
-
Roberto Vargas authored
RFC4122 defines that fields are stored in network order (big endian), but TF-A stores them in machine order (little endian by default in TF-A). We cannot change the future UUIDs that are already generated, but we can store all the bytes using arrays and modify fiptool to generate the UUIDs with the correct byte order. Change-Id: I97be2d3168d91f4dee7ccfafc533ea55ff33e46f Signed-off-by: Roberto Vargas <roberto.vargas@arm.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>
-