- 23 May, 2018 5 commits
-
-
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>
-
- 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 6 commits
-
-
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>
-
Jeenu Viswambharan authored
Previous patches added frameworks for handling RAS errors. This patch introduces features that the platform can use to enumerate and iterate RAS nodes: - The REGISTER_RAS_NODES() can be used to expose an array of ras_node_info_t structures. Each ras_node_info_t describes a RAS node, along with handlers for probing the node for error, and if did record an error, another handler to handle it. - The macro for_each_ras_node() can be used to iterate over the registered RAS nodes, probe for, and handle any errors. The common platform EA handler has been amended using error handling primitives introduced by both this and previous patches. Change-Id: I2e13f65a88357bc48cd97d608db6c541fad73853 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
The ARMv8 RAS Extensions introduced Standard Error Records which are a set of standard registers through which: - Platform can configure RAS node policy; e.g., notification mechanism; - RAS nodes can record and expose error information for error handling agents. Standard Error Records can either be accessed via. memory-mapped or System registers. This patch adds helper functions to access registers and fields within an error record. Change-Id: I6594ba799f4a1789d7b1e45b3e17fd40e7e0ba5c Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional extensions to base ARMv8.0 architecture. This patch adds build system support to enable RAS features in ARM Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for this. With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is inserted at all EL3 vector entry and exit. ESBs will synchronize pending external aborts before entering EL3, and therefore will contain and attribute errors to lower EL execution. Any errors thus synchronized are detected via. DISR_EL1 register. When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1. Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
At present, any External Abort routed to EL3 is reported as an unhandled exception and cause a panic. This patch enables ARM Trusted Firmware to handle External Aborts routed to EL3. With this patch, when an External Abort is received at EL3, its handling is delegated to plat_ea_handler() function. Platforms can provide their own implementation of this function. This patch adds a weak definition of the said function that prints out a message and just panics. In order to support handling External Aborts at EL3, the build option HANDLE_EA_EL3_FIRST must be set to 1. Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to compilation; this patch fixes that too. Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 02 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
Change-Id: Ice141dcc17f504025f922acace94d98f84acba9e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 01 May, 2018 1 commit
-
-
Roberto Vargas authored
Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 27 Apr, 2018 2 commits
-
-
Masahiro Yamada authored
Since commit 031dbb12 ("AArch32: Add essential Arch helpers"), it is difficult to use consistent format strings for printf() family between aarch32 and aarch64. For example, uint64_t is defined as 'unsigned long long' for aarch32 and as 'unsigned long' for aarch64. Likewise, uintptr_t is defined as 'unsigned int' for aarch32, and as 'unsigned long' for aarch64. A problem typically arises when you use printf() in common code. One solution could be, to cast the arguments to a type long enough for both architectures. For example, if 'val' is uint64_t type, like this: printf("val = %llx\n", (unsigned long long)val); Or, somebody may suggest to use a macro provided by <inttypes.h>, like this: printf("val = %" PRIx64 "\n", val); But, both would make the code ugly. The solution adopted in Linux kernel is to use the same typedefs for all architectures. The fixed integer types in the kernel-space have been unified into int-ll64, like follows: typedef signed char int8_t; typedef unsigned char uint8_t; typedef signed short int16_t; typedef unsigned short uint16_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef signed long long int64_t; typedef unsigned long long uint64_t; [ Linux commit: 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf ] This gets along with the codebase shared between 32 bit and 64 bit, with the data model called ILP32, LP64, respectively. The width for primitive types is defined as follows: ILP32 LP64 int 32 32 long 32 64 long long 64 64 pointer 32 64 'long long' is 64 bit for both, so it is used for defining uint64_t. 'long' has the same width as pointer, so for uintptr_t. We still need an ifdef conditional for (s)size_t. All 64 bit architectures use "unsigned long" size_t, and most 32 bit architectures use "unsigned int" size_t. H8/300, S/390 are known as exceptions; they use "unsigned long" size_t despite their architecture is 32 bit. One idea for simplification might be to define size_t as 'unsigned long' across architectures, then forbid the use of "%z" string format. However, this would cause a distortion between size_t and sizeof() operator. We have unknowledge about the native type of sizeof(), so we need a guess of it anyway. I want the following formula to always return 1: __builtin_types_compatible_p(size_t, typeof(sizeof(int))) Fortunately, ARM is probably a majority case. As far as I know, all 32 bit ARM compilers use "unsigned int" size_t. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
u_register_t is preferred rather than uint64_t. This is more consistent with the aarch32 implementation. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 26 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
According to the ARMv8 ARM issue C.a: AP[1] is valid only for stage 1 of a translation regime that can support two VA ranges. It is RES 1 when stage 1 translations can support only one VA range. This means that, even though this bit is ignored, it should be set to 1 in the EL3 and EL2 translation regimes. For translation regimes consisting on EL0 and a higher regime this bit selects between control at EL0 or at the higher Exception level. The regimes that support two VA ranges are EL1&0 and EL2&0 (the later one is only available since ARMv8.1). This fix has to be applied to both versions of the translation tables library. Change-Id: If19aaf588551bac7aeb6e9a686cf0c2068e7c181 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
Due to differences in the bitfields of the SMC IDs, it is not possible to support SMCCC 1.X and 2.0 at the same time. The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build option that specifies the major version of the SMCCC that the Trusted Firmware supports. The only two allowed values are 1 and 2, and it defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it. Note: Support for SMCCC v2.0 is an experimental feature to enable prototyping of secure partition specifications. Support for this convention is disabled by default and could be removed without notice. Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 17 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
Change-Id: I989c1f4aef8e3cb20d5d19e6347575e6449bb60b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 12 Apr, 2018 1 commit
-
-
Jonathan Wright authored
A fix for errata 843419 may be available in revision r0p4 of the Cortex-A53 processor. The presence of the fix is determined by checking bit 8 in the REVIDR register. If the fix is present we report ERRATA_NOT_APPLIES which silences the erroneous 'missing workaround' warning. Change-Id: Ibd2a478df3e2a6325442a6a48a0bb0259dcfc1d7 Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
-
- 27 Mar, 2018 1 commit
-
-
Joel Hutton authored
Void pointers have been used to access linker symbols, by declaring an extern pointer, then taking the address of it. This limits symbols values to aligned pointer values. To remove this restriction an IMPORT_SYM macro has been introduced, which declares it as a char pointer and casts it to the required type. Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0 Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>
-
- 26 Mar, 2018 1 commit
-
-
Jonathan Wright authored
Ensure (where possible) that switch statements in lib comply with MISRA rules 16.1 - 16.7. Change-Id: I52bc896fb7094d2b7569285686ee89f39f1ddd84 Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
-
- 21 Mar, 2018 1 commit
-
-
Antonio Nino Diaz authored
When the source code says 'SMCC' it is talking about the SMC Calling Convention. The correct acronym is SMCCC. This affects a few definitions and file names. Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S) but the old files have been kept for compatibility, they include the new ones with an ERROR_DEPRECATED guard. Change-Id: I78f94052a502436fdd97ca32c0fe86bd58173f2f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 14 Mar, 2018 2 commits
-
-
Dimitris Papastamos authored
When querying `SMCCC_ARCH_WORKAROUND_1` through `SMCCC_ARCH_FEATURES`, return either: * -1 to indicate the PE on which `SMCCC_ARCH_FEATURES` is called requires firmware mitigation for CVE-2017-5715 but the mitigation is not compiled in. * 0 to indicate that firmware mitigation is required, or * 1 to indicate that no firmware mitigation is required. This patch complies with v1.2 of the firmware interfaces specification (ARM DEN 0070A). Change-Id: Ibc32d6620efdac6c340758ec502d95554a55f02a Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
If the CSV2 field reads as 1 then branch targets trained in one context cannot affect speculative execution in a different context. In that case skip the workaround on Cortex A72 and A73. Change-Id: Ide24fb6efc77c548e4296295adc38dca87d042ee Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 28 Feb, 2018 3 commits
-
-
Roberto Vargas authored
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined Fixed for: make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all Change-Id: I7c2ad3f5c015411c202605851240d5347e4cc8c7 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
Roberto Vargas authored
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined. Change-Id: I26e042cb251a6f9590afa1340fdac73e42f23979 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
Roberto Vargas authored
Rule 8.3: All declarations of an object or function shall use the same names and type qualifiers. Change-Id: Iff384187c74a598a4e73f350a1893b60e9d16cec Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 27 Feb, 2018 6 commits
-
-
David Cunado authored
MISRA C-2012 Rule 7.3 violation: lowercase l shall not be used as literal suffixes. This patch resolves this for the ULL() macro by using ULL suffix instead of the ull suffix. Change-Id: Ia8183c399e74677e676956e8653e82375d0e0a01 Signed-off-by: David Cunado <david.cunado@arm.com>
-
Dimitris Papastamos authored
Change-Id: I61c9fdfda0c0b3c3ec6249519db23602cf4c2100 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
This patch also fixes the assumption that the counters are disabled on the resume path. This is incorrect as the AMU counters are enabled early in the CPU reset function before `cpuamu_context_restore()` runs. Change-Id: I38a94eb166a523f00de18e86860434ffccff2131 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
This patch also fixes `cpuamu_write_cpuamcntenclr_el0()` to use an MSR instruction instead of an MRS instruction. Change-Id: Ia6531f64b5ebc60ba432124eaa8d8eaccba40ed0 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Implement helpers to test if the core supports SPE/SVE. We have a similar helper for AMU and this patch makes all extensions consistent in their implementation. Change-Id: I3e6f7522535ca358259ad142550b19fcb883ca67 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Antonio Nino Diaz authored
When the MMU is enabled and the translation tables are mapped, data read/writes to the translation tables are made using the attributes specified in the translation tables themselves. However, the MMU performs table walks with the attributes specified in TCR_ELx. They are completely independent, so special care has to be taken to make sure that they are the same. This has to be done manually because it is not practical to have a test in the code. Such a test would need to know the virtual memory region that contains the translation tables and check that for all of the tables the attributes match the ones in TCR_ELx. As the tables may not even be mapped at all, this isn't a test that can be made generic. The flags used by enable_mmu_xxx() have been moved to the same header where the functions are. Also, some comments in the linker scripts related to the translation tables have been fixed. Change-Id: I1754768bffdae75f53561b1c4a5baf043b45a304 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 15 Feb, 2018 1 commit
-
-
Antonio Nino Diaz authored
According to the SMC Calling Convention (ARM DEN0028B): The Unknown SMC Function Identifier is a sign-extended value of (-1) that is returned in R0, W0 or X0 register. The value wasn't sign-extended because it was defined as a 32-bit unsigned value (0xFFFFFFFF). SMC_PREEMPT has been redefined as -2 for the same reason. NOTE: This might be a compatibility break for some AArch64 platforms that don't follow the previous version of the SMCCC (ARM DEN0028A) correctly. That document specifies that only the bottom 32 bits of the returned value must be checked. If a platform relies on the top 32 bits of the result being 0 (so that SMC_UNK is 0x00000000FFFFFFFF), it will have to fix its code to comply with the SMCCC. Change-Id: I7f7b109f6b30c114fe570aa0ead3c335383cb54d Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 01 Feb, 2018 1 commit
-
-
Masahiro Yamada authored
This commit adds some more files to use zlib from TF. To use zlib, ->zalloc and ->zfree hooks are needed. The implementation depends on the system. For user-space, the libc provides malloc() and friends. Unfortunately, ARM Trusted Firmware does not provide malloc() or any concept of dynamic memory allocation. I implemented very simple calloc() and free() for this. Stupidly, zfree() never frees memory, but it works enough for this. The purpose of using zlib is to implement gunzip() - this function takes compressed data from in_buf, then dumps the decompressed data to oub_buf. The work_buf is used for memory allocation during the decompress. Upon exit, it updates in_buf and out_buf. If successful, in_buf points to the end of input data, out_buf to the end of the decompressed data. To use this feature, you need to do: - include lib/zlib/zlib.mk from your platform.mk - add $(ZLIB_SOURCES) to your BL*_SOURCES Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 31 Jan, 2018 2 commits
-
-
Joel Hutton authored
Add amu_context_save() and amu_context_restore() functions for aarch32 Change-Id: I4df83d447adeaa9d9f203e16dc5a919ffc04d87a Signed-off-by: Joel Hutton <joel.hutton@arm.com>
-
Joel Hutton authored
Change-Id: Id6dfe885a63561b1d2649521bd020367b96ae1af Signed-off-by: Joel Hutton <joel.hutton@arm.com>
-
- 29 Jan, 2018 2 commits
-
-
Dimitris Papastamos authored
In the initial implementation of this workaround we used a dedicated workaround context to save/restore state. This patch reduces the footprint as no additional context is needed. Additionally, this patch reduces the memory loads and stores by 20%, reduces the instruction count and exploits static branch prediction to optimize the SMC path. Change-Id: Ia9f6bf06fbf8a9037cfe7f1f1fb32e8aec38ec7d Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
SMCCC v1.1 comes with a relaxed calling convention for AArch64 callers. The caller only needs to save x0-x3 before doing an SMC call. This patch adds support for SMCCC_VERSION and SMCCC_ARCH_FEATURES. Refer to "Firmware Interfaces for mitigating CVE_2017_5715 System Software on Arm Systems"[0] for more information. [0] https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf Change-Id: If5b1c55c17d6c5c7cb9c2c3ed355d3a91cdad0a9 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-