- 08 Nov, 2017 1 commit
-
-
Antonio Nino Diaz authored
A Secure Partition is a software execution environment instantiated in S-EL0 that can be used to implement simple management and security services. Since S-EL0 is an unprivileged exception level, a Secure Partition relies on privileged firmware e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources: - Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers. A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex. The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following: - Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request. Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 16 Oct, 2017 1 commit
-
-
Jeenu Viswambharan authored
The back end GIC driver converts and assigns the interrupt type to suitable group. For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, which determines to which type Group 0 interrupts maps to. - When the build option is set 0 (the default), Group 0 interrupts are meant for Secure EL1. This is presently the case. - Otherwise, Group 0 interrupts are meant for EL3. This means the SPD will have to synchronously hand over the interrupt to Secure EL1. The query API allows the platform to query whether the platform supports interrupts of a given type. API documentation updated. Change-Id: I60fdb4053ffe0bd006b3b20914914ebd311fc858 Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 31 Aug, 2017 1 commit
-
-
Soby Mathew authored
The `KEY_ALG` variable is used to select the algorithm for key generation by `cert_create` tool for signing the certificates. This variable was previously undocumented and did not have a global default value. This patch corrects this and also adds changes to derive the value of `TF_MBEDTLS_KEY_ALG` based on `KEY_ALG` if it not set by the platform. The corresponding assignment of these variables are also now removed from the `arm_common.mk` makefile. Signed-off-by: Soby Mathew <soby.mathew@arm.com> Change-Id: I78e2d6f4fc04ed5ad35ce2266118afb63127a5a4
-
- 01 Aug, 2017 1 commit
-
-
Jeenu Viswambharan authored
The current build system and driver requires the CCI product to be specified at build time. The device constraints can be determined at run time from its ID registers, obviating the need for specifying them ahead. This patch adds changes to identify and validate CCI at run time. Some global variables are renamed to be in line with the rest of the code base. The build option ARM_CCI_PRODUCT_ID is now removed, and user guide is updated. Change-Id: Ibb765e349d3bc95ff3eb9a64bde1207ab710a93d Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 22 Jun, 2017 1 commit
-
-
dp-arm authored
SPE is only supported in non-secure state. Accesses to SPE specific registers from SEL1 will trap to EL3. During a world switch, before `TTBR` is modified the SPE profiling buffers are drained. This is to avoid a potential invalid memory access in SEL1. SPE is architecturally specified only for AArch64. Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 01 Jun, 2017 1 commit
-
-
Antonio Nino Diaz authored
It doesn't make sense to use the `-pedantic` flag when building the Trusted Firmware as we use GNU extensions and so our code is not fully ISO C compliant. This flag only makes sense if the code intends to be ISO C compliant. Change-Id: I6273564112759ff57f03b273f5349733a5f38aef Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 23 May, 2017 1 commit
-
-
Masahiro Yamada authored
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide any value (at least technically). For easier use of TBBR, this commit allows platforms to reuse the OIDs obtained by ARM Ltd. This will be useful for non-ARM vendors that do not need their own extension fields in their certificate files. The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by defining USE_TBBR_DEFS as 1. USE_TBBR_DEFS is 0 by default to keep the backward compatibility. For clarification, I inserted a blank line between headers from the include/ directory (#include <...>) and ones from a local directory (#include "..." ). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
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>
-
- 19 Apr, 2017 1 commit
-
-
Soby Mathew authored
This patch introduces a build option to enable D-cache early on the CPU after warm boot. This is applicable for platforms which do not require interconnect programming to enable cache coherency (eg: single cluster platforms). If this option is enabled, then warm boot path enables D-caches immediately after enabling MMU. Fixes ARM-Software/tf-issues#456 Change-Id: I44c8787d116d7217837ced3bcf0b1d3441c8d80e Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 31 Mar, 2017 1 commit
-
-
Douglas Raillard authored
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>
-
- 02 Mar, 2017 1 commit
-
-
Jeenu Viswambharan authored
The boolean build option HW_ASSISTED_COHERENCY is introduced to enable various optimizations in ARM Trusted Software, when built for such systems. It's set to 0 by default. Change-Id: I638390da6e1718fe024dcf5b402e07084f1eb014 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 14 Feb, 2017 1 commit
-
-
Jeenu Viswambharan authored
The ARMv8v.1 architecture extension has introduced support for far atomics, which includes compare-and-swap. Compare and Swap instruction is only available for AArch64. Introduce build options to choose the architecture versions to target ARM Trusted Firmware: - ARM_ARCH_MAJOR: selects the major version of target ARM Architecture. Default value is 8. - ARM_ARCH_MINOR: selects the minor version of target ARM Architecture. Default value is 0. When: (ARM_ARCH_MAJOR > 8) || ((ARM_ARCH_MAJOR == 8) && (ARM_ARCH_MINOR >= 1)), for AArch64, Compare and Swap instruction is used to implement spin locks. Otherwise, the implementation falls back to using load-/store-exclusive instructions. Update user guide, and introduce a section in Firmware Design guide to summarize support for features introduced in ARMv8 Architecture Extensions. Change-Id: I73096a0039502f7aef9ec6ab3ae36680da033f16 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 28 Jan, 2017 1 commit
-
-
Masahiro Yamada authored
The current fiptool packs all the images without any padding between them. So, the offset to each image has no alignment. This is not efficient, for example, when the FIP is read from a block-oriented device. For example, (e)MMC is accessed by block-addressing. The block size is 512 byte. So, the best case is each image is aligned by 512 byte since the DMA engine can transfer the whole of the image to its load address directly. The worst case is the offset does not have even DMA-capable alignment (this is where we stand now). In this case, we need to transfer every block to a bounce buffer, then do memcpy() from the bounce buffer to our final destination. At least, this should work with the abstraction by the block I/O layer, but the CPU-intervention for the whole data transfer makes it really slow. This commit adds a new option --align to the fiptool. This option, if given, requests the tool to align each component in the FIP file by the specified byte. Also, add a new Make option FIP_ALIGN for easier access to this feature; users can give something like FIP_ALIGN=512 from the command line, or add "FIP_ALIGN := 512" to their platform.mk file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 08 Nov, 2016 1 commit
-
-
Jeenu Viswambharan authored
When build variables are assigned or processed en masse, they'd appear neater in alphabetical order. Static initializations are moved to a separate file, make_helpers/defaults.mk, which in itself is sorted alphabetically. No functional changes. Change-Id: I966010042b33de6b67592fb9ffcef8fc44d7d128 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-