- 04 Oct, 2019 1 commit
-
-
Soby Mathew authored
Make the spinlock implementation use ARMv8.1-LSE CAS instruction based on a platform build option. The CAS-based implementation used to be unconditionally selected for all ARM8.1+ platforms. The previous CAS spinlock implementation had a bug wherein the spin_unlock() implementation had an `sev` after `stlr` which is not sufficient. A dsb is needed to ensure that the stlr completes prior to the sev. Having a dsb is heavyweight and a better solution would be to use load exclusive semantics to monitor the lock and wake up from wfe when a store happens to the lock. The patch implements the same. Change-Id: I5283ce4a889376e4cc01d1b9d09afa8229a2e522 Signed-off-by: Soby Mathew <soby.mathew@arm.com> Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
-
- 12 Sep, 2019 1 commit
-
-
Hadi Asyrafi authored
Some of the platform (ie. Agilex) make use of CCU IPs which will only be initialized during bl2_el3_early_platform_setup. Any operation to the cache beforehand will crash the platform. Hence, this will provide an option to skip the data cache invalidation upon bl2 entry at EL3 Signed-off-by: Hadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com> Change-Id: I2c924ed0589a72d0034714c31be8fe57237d1f06
-
- 11 Sep, 2019 1 commit
-
-
Justin Chadwell authored
This patch adds support for the Undefined Behaviour sanitizer. There are two types of support offered - minimalistic trapping support which essentially immediately crashes on undefined behaviour and full support with full debug messages. The full support relies on ubsan.c which has been adapted from code used by OPTEE. Change-Id: I417c810f4fc43dcb56db6a6a555bfd0b38440727 Signed-off-by: Justin Chadwell <justin.chadwell@arm.com>
-
- 09 Sep, 2019 1 commit
-
-
Justin Chadwell authored
This patch adds support for the new Memory Tagging Extension arriving in ARMv8.5. MTE support is now enabled by default on systems that support at EL0. To enable it at ELx for both the non-secure and the secure world, the compiler flag CTX_INCLUDE_MTE_REGS includes register saving and restoring when necessary in order to prevent register leakage between the worlds. Change-Id: I2d4ea993d6b11654ea0d4757d00ca20d23acf36c Signed-off-by: Justin Chadwell <justin.chadwell@arm.com>
-
- 28 Jun, 2019 1 commit
-
-
Ambroise Vincent authored
The new API becomes the default one. Change-Id: Ic1d602da3dff4f4ebbcc158b885295c902a24fec Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
-
- 26 Jun, 2019 1 commit
-
-
Ambroise Vincent authored
This interface has been deprecated in favour of MULTI_CONSOLE_API. Change-Id: I6170c1c8c74a890e5bd6d05396743fe62024a08a Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
-
- 24 May, 2019 1 commit
-
-
Alexei Fedorov authored
This patch adds the functionality needed for platforms to provide Branch Target Identification (BTI) extension, introduced to AArch64 in Armv8.5-A by adding BTI instruction used to mark valid targets for indirect branches. The patch sets new GP bit [50] to the stage 1 Translation Table Block and Page entries to denote guarded EL3 code pages which will cause processor to trap instructions in protected pages trying to perform an indirect branch to any instruction other than BTI. BTI feature is selected by BRANCH_PROTECTION option which supersedes the previous ENABLE_PAUTH used for Armv8.3-A Pointer Authentication and is disabled by default. Enabling BTI requires compiler support and was tested with GCC versions 9.0.0, 9.0.1 and 10.0.0. The assembly macros and helpers are modified to accommodate the BTI instruction. This is an experimental feature. Note. The previous ENABLE_PAUTH build option to enable PAuth in EL3 is now made as an internal flag and BRANCH_PROTECTION flag should be used instead to enable Pointer Authentication. Note. USE_LIBROM=1 option is currently not supported. Change-Id: Ifaf4438609b16647dc79468b70cd1f47a623362e Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 02 May, 2019 1 commit
-
-
Christoph Müllner authored
On certain platforms it does not make sense to generate TF-A binary images. For example a platform could make use of serveral memory areas, which are non-continuous and the resulting binary therefore would suffer from the padding-bytes. Typically these platforms use the ELF image. This patch introduces a variable DISABLE_BIN_GENERATION, which can be set to '1' in the platform makefile to prevent the binary generation. Signed-off-by: Christoph Müllner <christophm30@gmail.com> Change-Id: I62948e88bab685bb055fe6167d9660d14e604462
-
- 28 Feb, 2019 1 commit
-
-
Antonio Nino Diaz authored
Fix some typos and clarify some sentences. Change-Id: Id276d1ced9a991b4eddc5c47ad9a825e6b29ef74 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 27 Feb, 2019 2 commits
-
-
Antonio Nino Diaz authored
The previous commit added the infrastructure to load and save ARMv8.3-PAuth registers during Non-secure <-> Secure world switches, but didn't actually enable pointer authentication in the firmware. This patch adds the functionality needed for platforms to provide authentication keys for the firmware, and a new option (ENABLE_PAUTH) to enable pointer authentication in the firmware itself. This option is disabled by default, and it requires CTX_INCLUDE_PAUTH_REGS to be enabled. Change-Id: I35127ec271e1198d43209044de39fa712ef202a5 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
ARMv8.3-PAuth adds functionality that supports address authentication of the contents of a register before that register is used as the target of an indirect branch, or as a load. This feature is supported only in AArch64 state. This feature is mandatory in ARMv8.3 implementations. This feature adds several registers to EL1. A new option called CTX_INCLUDE_PAUTH_REGS has been added to select if the TF needs to save them during Non-secure <-> Secure world switches. This option must be enabled if the hardware has the registers or the values will be leaked during world switches. To prevent leaks, this patch also disables pointer authentication in the Secure world if CTX_INCLUDE_PAUTH_REGS is 0. Any attempt to use it will be trapped in EL3. Change-Id: I27beba9907b9a86c6df1d0c5bf6180c972830855 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 05 Feb, 2019 1 commit
-
-
Varun Wadekar authored
This patch introduces a build option 'OVERRIDE_LIBC' that platforms can set to override libc from the BL image. The default value is '0' to keep the library. Change-Id: I10a0b247f6a782eeea4a0359e30a8d79b1e9e4e1 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 30 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
This reverts commit 2f370465 ("Add support for the SMC Calling Convention 2.0"). SMCCC v2.0 is no longer required for SPM, and won't be needed in the future. Removing it makes the SMC handling code less complicated. The SPM implementation based on SPCI and SPRT was using it, but it has been adapted to SMCCC v1.0. Change-Id: I36795b91857b2b9c00437cfbfed04b3c1627f578 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 22 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
The SPM implementation based on MM is going to be kept for the foreseeable future. Change-Id: I11e96778a4f52a1aa803e7e048d9a7cb24a53954 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Acked-by: Sumit Garg <sumit.garg@linaro.org>
-
- 10 Dec, 2018 1 commit
-
-
Antonio Nino Diaz authored
The current SPM is a prototype that only supports one secure partition in EL0. The objective of SPM is to have multiple partitions. The current MM interface isn't adequate for this, so it is needed to modify heavily the code to add proper support for it. However, there are platforms which are already using this (like SGI) and removing the code would break it. For this reason, the current SPM code has been duplicated in order to temporarily preserve compatibility. All new improvements/changes to SPM will be done in the non-deprecated copy, that may change without notice. The new build option SPM_DEPRECATED has been introduced to select the SPM implementation. It defaults to 1, that selects the deprecated SPM. Change-Id: Ic9f80b53b450e97b4d3f47e4ef4a138ee8d87443 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 29 Oct, 2018 1 commit
-
-
Soby Mathew authored
Change-Id: I0b8ccba15024c55bb03927cdb50370913eb8010c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 03 Oct, 2018 1 commit
-
-
Daniel Boulby authored
This patch introduces a build flag "RECLAIM_INIT_CODE" to mark boot time code which allows platforms to place this memory in an appropriate section to be reclaimed later. This features is primarily targeted for BL31. Appropriate documentation updates are also done. Change-Id: If0ca062851614805d769c332c771083d46599194 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 28 Sep, 2018 3 commits
-
-
Antonio Nino Diaz authored
Change-Id: I567a406edb090ae9d109382f6874846a79dd7473 Co-authored-by: Roberto Vargas <roberto.vargas@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Change-Id: I2885b0d8cb9bb16da1fa96a30e46cccde434dc42 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Roberto Vargas authored
The code of LOAD_IMAGE_V2=0 has been removed. Change-Id: Iea03e5bebb90c66889bdb23f85c07d0c9717fffe Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 30 Aug, 2018 1 commit
-
-
Antonio Nino Diaz authored
At the moment the AArch32 instruction set isn't specified in the command line, which means that the compiler is free to choose the one it sees fit. This decision may change between compiler versions, so it is better to specify it manually. The build option AARCH32_INSTRUCTION_SET has been introduced for this reason. This option can be set to T32 or A32 to pass the correct flags to the compiler. The current behaviour is to default to T32 due to it's smaller size. Change-Id: I02297eb1d9404b5868ff7c054fbff9b3cda7fdb6 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 20 Aug, 2018 1 commit
-
-
Jeenu Viswambharan authored
Memory Partitioning And Monitoring is an Armv8.4 feature that enables various memory system components and resources to define partitions. Software running at various ELs can then assign themselves to the desired partition to control their performance aspects. With this patch, when ENABLE_MPAM_FOR_LOWER_ELS is set to 1, EL3 allows lower ELs to access their own MPAM registers without trapping to EL3. This patch however doesn't make use of partitioning in EL3; platform initialisation code should configure and use partitions in EL3 if required. Change-Id: I5a55b6771ccaa0c1cffc05543d2116b60cbbcdcd Co-authored-by: James Morse <james.morse@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 03 Aug, 2018 1 commit
-
-
Roberto Vargas authored
Romlib is a new image that is stored in ROM and contains the code of several libraries that can be shared between different images. All the functions within in the library are accessed using a jump table which allows to update the romlib image whithout changing the binary compatibility. This jump table can be also stored in RAM and it can allow to patch a romlib with potential bugs fixes.. Change-Id: If980ccdaca24b7aaca900e32acc68baf6f94ab35 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 18 May, 2018 1 commit
-
-
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>
-
- 04 May, 2018 3 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
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>
-
- 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>
-
- 07 Apr, 2018 1 commit
-
-
Jiafei Pan authored
In some use-cases BL2 will be stored in eXecute In Place (XIP) memory, like BL1. In these use-cases, it is necessary to initialize the RW sections in RAM, while leaving the RO sections in place. This patch enable this use-case with a new build option, BL2_IN_XIP_MEM. For now, this option is only supported when BL2_AT_EL3 is 1. Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
-
- 01 Mar, 2018 1 commit
-
-
Dan Handley authored
For platforms that have not migrated to MULTI_CONSOLE_API == 1, there are a lot of confusing deprecated declaration warnings relating to use of console_init() and console_uninit(). Some of these relate to use by the generic code, not the platform code. These functions are not really deprecated but *removed* when MULTI_CONSOLE_API == 1. This patch consolidates these warnings into a single preprocessor warning. The __deprecated attribute is removed from the console_init() and console_uninit() declarations. For preprocessor warnings like this to not cause fatal build errors, this patch adds -Wno-error=cpp to the build flags when ERROR_DEPRECATED == 0. This option (and -Wno-error=deprecated-declarations) is now added to CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the assembler as well as the compiler. This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED build flags by defaulting MULTI_CONSOLE_API to 0 instead of ERROR_DEPRECATED. This allows platforms that have not migrated to MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful build error. Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since the AArch32 console implementation does not support MULTI_CONSOLE_API == 1. Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c Signed-off-by: Dan Handley <dan.handley@arm.com>
-
- 19 Jan, 2018 1 commit
-
-
Julius Werner authored
This patch adds the foundation for a platform-independent coreboot support library that can be shared by all platforms that boot BL31 from coreboot (acting as BL2). It adds code to parse the "coreboot table", a data structure that coreboot uses to communicate different kinds of information to later-stage firmware and certain OS drivers. As a first small use case for this information, allow platforms to access the serial console configuration used by coreboot, removing the need to hardcode base address and divisors and allowing Trusted Firmware to benefit from coreboot's user configuration (e.g. which UART to pick and which baud rate to use). Change-Id: I2bfb39cd2609ce6640b844ab68df6c9ae3f28e9e Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 18 Jan, 2018 1 commit
-
-
Roberto Vargas authored
This patch enables BL2 to execute at the highest exception level without any dependancy on TF BL1. This enables platforms which already have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL stages without need for BL1. This is not currently possible because BL2 executes at S-EL1 and cannot jump straight to EL3. Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 12 Dec, 2017 1 commit
-
-
Julius Werner authored
This patch overhauls the console API to allow for multiple console instances of different drivers that are active at the same time. Instead of binding to well-known function names (like console_core_init), consoles now provide a register function (e.g. console_16550_register()) that will hook them into the list of active consoles. All console operations will be dispatched to all consoles currently in the list. The new API will be selected by the build-time option MULTI_CONSOLE_API, which defaults to ${ERROR_DEPRECATED} for now. The old console API code will be retained to stay backwards-compatible to older platforms, but should no longer be used for any newly added platforms and can hopefully be removed at some point in the future. The new console API is intended to be used for both normal (bootup) and crash use cases, freeing platforms of the need to set up the crash console separately. Consoles can be individually configured to be active active at boot (until first handoff to EL2), at runtime (after first handoff to EL2), and/or after a crash. Console drivers should set a sane default upon registration that can be overridden with the console_set_scope() call. Code to hook up the crash reporting mechanism to this framework will be added with a later patch. This patch only affects AArch64, but the new API could easily be ported to AArch32 as well if desired. Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549 Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 30 Nov, 2017 1 commit
-
-
David Cunado authored
This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set to one EL3 will check to see if the Scalable Vector Extension (SVE) is implemented when entering and exiting the Non-secure world. If SVE is implemented, EL3 will do the following: - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled. - Exit from Non-secure world: SIMD, FP and SVE functionality is disabled. As SIMD and FP registers are part of the SVE Z-registers then any use of SIMD / FP functionality would corrupt the SVE registers. The build option default is 1. The SVE functionality is only supported on AArch64 and so the build option is set to zero when the target archiecture is AArch32. This build option is not compatible with the CTX_INCLUDE_FPREGS - an assert will be raised on platforms where SVE is implemented and both ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1. Also note this change prevents secure world use of FP&SIMD registers on SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on such platforms unless ENABLE_SVE_FOR_NS is set to 0. Additionally, on the first entry into the Non-secure world the SVE functionality is enabled and the SVE Z-register length is set to the maximum size allowed by the architecture. This includes the use case where EL2 is implemented but not used. Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 29 Nov, 2017 1 commit
-
-
Dimitris Papastamos authored
The Cortex A75 has 5 AMU counters. The first three counters are fixed and the remaining two are programmable. A new build option is introduced, `ENABLE_AMU`. When set, the fixed counters will be enabled for use by lower ELs. The programmable counters are currently disabled. Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 23 Nov, 2017 1 commit
-
-
Matt Ma authored
This patch replaces the macro ASM_ASSERTION with the macro ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor related files. There is build error when ASM_ASSERTION is set to 1 and ENABLE_ASSERTIONS is set to 0 because function asm_assert in common/aarch32/debug.S is defined in the macro ENABLE_ASSERTIONS but is called with the macro ASM_ASSERTION. There is also the indication to use ENABLE_ASSERTIONS but not ASM_ASSERTION in the Makefile. Signed-off-by: Matt Ma <matt.ma@spreadtrum.com>
-
- 20 Nov, 2017 1 commit
-
-
Dimitris Papastamos authored
It is not possible to detect at compile-time whether support for an optional extension such as SPE should be enabled based on the ARM_ARCH_MINOR build option value. Therefore SPE is now enabled by default. Change-Id: I670db164366aa78a7095de70a0962f7c0328ab7c Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 13 Nov, 2017 2 commits
-
-
Jeenu Viswambharan authored
The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1]. Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31. Update user guide and porting guide. SDEI documentation to follow. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3. This framework facilitates the firmware-first error handling policy in which asynchronous exceptions may be routed to EL3. Such exceptions may be handed over to respective exception handlers. Individual handlers might further delegate exception handling to lower ELs. The framework associates the delegated execution to lower ELs with a priority value. For interrupts, this corresponds to the priorities programmed in GIC; for other types of exceptions, viz. SErrors or Synchronous External Aborts, individual dispatchers shall explicitly associate delegation to a secure priority. In order to prevent lower priority interrupts from preempting higher priority execution, the framework provides helpers to control preemption by virtue of programming Priority Mask register in the interrupt controller. This commit allows for handling interrupts targeted at EL3. Exception handlers own interrupts by assigning them a range of secure priorities, and registering handlers for each priority range it owns. Support for exception handling in BL31 image is enabled by setting the build option EL3_EXCEPTION_HANDLING=1. Documentation to follow. NOTE: The framework assumes the priority scheme supported by platform interrupt controller is compliant with that of ARM GIC architecture (v2 or later). Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 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>
-