| /rk3399_ARM-atf/docs/design/ |
| H A D | trusted-board-boot.rst | 5 on the platform by authenticating all firmware images up to and including the
9 This document describes the design of Trusted Firmware-A (TF-A) TBB, which is an
10 implementation of the `Trusted Board Boot Requirements (TBBR)`_ specification,
11 Arm DEN0006D. It should be used in conjunction with the :ref:`Firmware Update
12 (FWU)` design document, which implements a specific aspect of the TBBR.
18 are used to establish trust in the next layer of components, and so on, in a
27 - The key provisioning scheme: which keys need to programmed into the device
28 and at which stage during the platform's manufacturing lifecycle.
38 The implicitly trusted components forming the trust anchor are:
42 On Arm development platforms, a hash of the ROTPK (hash algorithm selected by
[all …]
|
| H A D | auth-framework.rst | 4 The aim of this document is to describe the authentication framework
5 implemented in Trusted Firmware-A (TF-A). This framework fulfills the
8 #. It should be possible for a platform port to specify the Chain of Trust in
9 terms of certificate hierarchy and the mechanisms used to verify a
18 - The mechanism used to verify the transported information i.e. the
21 The framework has been designed following a modular approach illustrated in the
62 This document describes the inner details of the authentication framework and
63 the abstraction mechanisms available to specify a Chain of Trust.
68 This section describes some aspects of the framework design and the rationale
76 illustrates how this maps to a CoT for the BL31 image described in the
[all …]
|
| H A D | interrupt-framework-design.rst | 5 allows EL3 software to configure the interrupt routing behavior. Its main
6 objective is to implement the following two requirements.
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
12 software configuration and the GIC implementation. This requirement ensures
13 that secure interrupts are under the control of the secure software with
14 respect to their delivery and handling without the possibility of
18 non-secure software (Non-secure interrupts) to the last executed exception
19 level in the normal world when the execution is in secure world at
20 exception levels lower than EL3. This could be done with or without the
22 approach should be governed by the secure software. This requirement
[all …]
|
| H A D | psci-pd-tree.rst | 7 #. A platform must export the ``plat_get_aff_count()`` and
8 ``plat_get_aff_state()`` APIs to enable the generic PSCI code to
9 populate a tree that describes the hierarchy of power domains in the
10 system. This approach is inflexible because a change to the topology
11 requires a change in the code.
13 It would be much simpler for the platform to describe its power domain tree
16 #. The generic PSCI code generates MPIDRs in order to populate the power domain
17 tree. It also uses an MPIDR to find a node in the tree. The assumption that
18 a platform will use exactly the same MPIDRs as generated by the generic PSCI
19 code is not scalable. The use of an MPIDR also restricts the number of
[all …]
|
| H A D | trusted-board-boot-build.rst | 4 Trusted Board Boot primarily consists of the following two features:
12 #. Fulfill the dependencies of the ``mbedtls`` cryptographic and image parser
13 modules by checking out a recent version of the `mbed TLS Repository`_. It
16 information. See the :ref:`Prerequisites` document for the appropriate
19 The ``drivers/auth/mbedtls/mbedtls_*.mk`` files contain the list of mbed TLS
20 source files the modules depend upon.
21 ``include/drivers/auth/mbedtls/mbedtls_config.h`` contains the configuration
22 options required to build the mbed TLS sources.
24 Note that the mbed TLS library is licensed under the Apache version 2.0
25 license. Using mbed TLS source code will affect the licensing of TF-A
[all …]
|
| H A D | reset-design.rst | 4 This document describes the high-level design of the framework to handle CPU
5 resets in Trusted Firmware-A (TF-A). It also describes how the platform
6 integrator can tailor this code to the system configuration to some extent,
9 This document should be used in conjunction with the :ref:`Firmware Design`
10 document which provides greater implementation details around the reset code,
11 specifically for the cold boot path.
21 This diagram shows the default, unoptimised reset flow. Depending on the system
23 guide the platform integrator by indicating which build options exclude which
24 steps, depending on the capability of the platform.
27 If BL31 is used as the TF-A entry point instead of BL1, the diagram
[all …]
|
| H A D | firmware-design.rst | 4 Trusted Firmware-A (TF-A) implements a subset of the Trusted Board Boot
8 The TBB sequence starts when the platform is powered on and runs up
9 to the stage where it hands-off control to firmware running in the normal
10 world in DRAM. This is the cold boot path.
12 TF-A also implements the `PSCI`_ as a runtime service. PSCI is the interface
15 access TF-A runtime services via the Arm SMC (Secure Monitor Call) instruction.
16 The SMC instruction must be used as mandated by the SMC Calling Convention
20 in either security state. The details of the interrupt management framework
23 TF-A also implements a library for setting up and managing the translation
30 The descriptions in this chapter are for the Arm TrustZone architecture.
[all …]
|
| /rk3399_ARM-atf/docs/components/ |
| H A D | platform-interrupt-controller-API.rst | 4 This document lists the optional platform interrupt controller API that
5 abstracts the runtime configuration and control of interrupt controller from the
6 generic code. The mandatory APIs are described in the
17 This API should return the priority of the interrupt the PE is currently
21 In the case of Arm standard platforms using GIC, the *Running Priority Register*
22 is read to determine the priority of the interrupt.
32 The API should return whether the interrupt ID (first parameter) is categorized
35 the system.
45 The API should return whether the interrupt ID (first parameter) is categorized
58 The API should return whether the interrupt ID (first parameter) is categorized
[all …]
|
| H A D | ffa-manifest-binding.rst | 4 This document defines the nodes and properties used to define a partition,
5 according to the FF-A specification, and the SPMC manifest.
10 The FF-A partition manifest is consumed by the SPMC to configure the state
11 associated with the related Secure Partition.
15 - Must be the string "arm,ffa-manifest-X.Y" which specifies the major and
16 minor versions of the device tree binding for the FFA manifest represented
17 by this node. The minor number is incremented if the binding changes in a
20 - X is an integer representing the major version number of this document.
21 - Y is an integer representing the minor version number of this document.
28 - X is the major version of FF-A expected by the partition at the FFA
[all …]
|
| H A D | romlib-design.rst | 4 This document provides an overview of the "library at ROM" implementation in
11 be placed in ROM. This reduces SRAM usage by utilising the available space in
12 ROM. The "library at ROM" contains a jump table with the list of functions that
13 are placed in ROM. The capabilities of the "library at ROM" are:
29 Library at ROM is described by an index file with the list of functions to be
36 lib -- Name of the library the function belongs to
37 function -- Name of the function to be placed in library at ROM
38 [patch] -- Option to patch the function
40 It is also possible to insert reserved spaces in the list by using the keyword
41 "reserved" rather than the "lib" and "function" names as shown below:
[all …]
|
| H A D | xlat-tables-lib-v2-design.rst | 4 This document describes the design of the translation tables library (version 2)
6 tables based on a description of the memory layout, as well as setting up system
7 registers related to the Memory Management Unit (MMU) and performing the
13 on a description of the memory layout. The memory layout is typically
14 provided by the platform port as a list of memory regions;
17 translation regime than the exception level the library code is executing at;
19 #. Support for dynamic mapping and unmapping of regions, even while the MMU is
23 #. Support for non-identity virtual to physical mappings to compress the virtual
32 This document focuses on version 2 of the library, whose sources are available
33 in the ``lib/xlat_tables_v2`` directory. Version 1 of the library can still be
[all …]
|
| H A D | secure-partition-manager-mm.rst | 7 This document describes the implementation where the Secure Partition Manager
9 S-EL0. The communication protocol is established through the Management Mode
18 authentication. The Global Platform TEE Client API specification defines the API
20 fulfils the requirements of a security service as described above.
22 Management services are typically implemented at the highest level of privilege
23 in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
24 fulfilled by the execution environment provided by TF-A.
26 The following diagram illustrates the corresponding software stack:
31 centres and enterprise servers) the secure software stack typically does not
47 resources. Essentially, it is a software sandbox in the Secure world that runs
[all …]
|
| H A D | firmware-update.rst | 4 This document describes the design of the various Firmware Update (FWU)
10 PSA Firmware Update implements the specification of the same name (Arm document
13 On the other hand, TBBR Firmware Update only covers firmware recovery. Arguably,
14 its name is somewhat misleading but the TBBR specification and terminology
15 predates PSA FWU. Both mechanisms are complementary in the sense that PSA FWU
16 assumes that the device has a backup or recovery capability in the event of a
26 The `PSA FW update specification`_ defines the concepts of ``Firmware Update
28 The new firmware images are provided by the ``Client`` to the ``Update Agent``
31 A common system design will place the ``Update Agent`` in the Secure-world
32 while the ``Client`` executes in the Normal-world.
[all …]
|
| H A D | sdei.rst | 4 This document provides an overview of the SDEI dispatcher implementation in
12 about system events. Firmware will first receive the system events by way of
13 asynchronous exceptions and, in response, arranges for the registered handler to
14 execute in the Non-secure EL.
16 Normal world software that interacts with the SDEI dispatcher (makes SDEI
17 requests and receives notifications) is referred to as the *SDEI Client*. A
18 client receives the event notification at the registered handler even when it
19 was executing with exceptions masked. The list of SDEI events available to the
20 client are specific to the platform [#std-event]_. See also `Determining client
26 at EL2 and an event dispatch resulting from the triggering of a bound interrupt.
[all …]
|
| /rk3399_ARM-atf/docs/ |
| H A D | porting-guide.rst | 8 mandatory and optional modifications for both the cold and warm boot paths.
12 - Setting up the execution context in a certain way, or
17 implementation of variables and functions to fulfill the optional requirements
18 in order to ease the porting effort. Each platform port can use them as is or
19 provide their own implementation if the default implementation is inadequate.
25 interfaces as they get introduced in the code base should be *strongly*
29 Please review the :ref:`Threat Model` documents as part of the porting
31 the threats. Failing to fulfill these expectations could undermine the security
33 the threat assessment section, under the "`Mitigations implemented?`" box for
37 discusses these in detail. The subsequent sections discuss the remaining
[all …]
|
| /rk3399_ARM-atf/docs/perf/ |
| H A D | psci-performance-methodology.rst | 5 operations in the Trusted Firmware-A Power State Coordination Interface (PSCI)
6 implementation, using the in-built Performance Measurement Framework (PMF) and
12 The tests are based on the ``runtime-instrumentation`` test suite provided by
13 the Trusted Firmware Test Framework (TFTF). The release build of this framework
14 was used because the results in the debug build became skewed; the console
15 output prevented some of the tests from executing in parallel.
20 - **Parallel Tests** This type of test powers on all the non-lead CPUs and
21 brings them and the lead CPU to a common synchronization point. The lead CPU
22 then initiates the test on all CPUs in parallel.
25 sequence. The lead CPU initiates the test on a non-lead CPU then waits for the
[all …]
|
| H A D | psci-performance-instr.rst | 4 TF-A provides two instrumentation tools for performing analysis of the PSCI
18 at runtime from the Performance Measurement Unit
21 measure hardware events. This means, for instance, that the PMU might be used to
24 TF-A utilises the PMF as a backend for the two instrumentation services it
27 instance, the PSCI Statistics service registers the PMF service
30 This is reserved a unique ID, name, and space in memory by the PMF. The
32 values from ``psci_svc`` at runtime. Alternatively, the service may be
33 configured such that the PMF dumps those values to the console. A platform may
34 choose to expose SMCs that allow retrieval of these timestamps from the
37 This feature is enabled with the Boolean flag ``ENABLE_PMF``.
[all …]
|
| /rk3399_ARM-atf/docs/threat_model/firmware_threat_model/ |
| H A D | threat_model_rse_interface.rst | 7 This document is an extension for the general TF-A threat-model. It considers
8 those platforms where a Runtime Security Engine (RSE) is included in the SoC
9 next to the Application Processor (AP).
14 The scope of this threat model only includes the interface between the RSE and
15 AP. Otherwise, the TF-A :ref:`Generic Threat Model` document is applicable for
16 the AP core. The threat model for the RSE firmware will be provided by the RSE
17 firmware project in the future.
22 This diagram is different only from the general TF-A data flow diagram in that
23 it includes the RSE and highlights the interface between the AP and the RSE
24 cores. The interface description only focuses on the AP-RSE interface the rest
[all …]
|
| H A D | threat_model_fw_update_and_recovery.rst | 8 the feature PSA firmware update or TBBR firmware update or both enabled.
9 To understand the design of the firmware update refer
12 Although it is a separate document, it references the :ref:`Generic Threat
13 Model` in a number of places, as some of the contents are applicable to this
19 In this threat model, the target of evaluation is the Trusted Firmware for
21 is enabled. This includes the boot ROM (BL1), the trusted boot firmware (BL2).
26 For this section, please reference the Threat Assessment under the
27 :ref:`Generic Threat Model`. Here only the differences are highlighted.
32 Threats to be Mitigated by the Boot Firmware
35 The following table analyses the :ref:`Boot Firmware Threats` in the context
[all …]
|
| /rk3399_ARM-atf/docs/design_documents/ |
| H A D | drtm_poc.rst | 6 and formal definition of DRTM for Arm-based systems are detailed in the
10 currently used by TF-A covers all firmwares, from the boot ROM to the normal
11 world bootloader. As a whole, they make up the system's TCB. These boot
12 measurements allow attesting to what software is running on the system and
15 As the boot chain grows or firmware becomes dynamically extensible,
18 any time. As these measurements are stored separately from the boot-time
19 measurements, they reduce the size of the TCB, which helps reduce the attack
20 surface and the risk of untrusted code executing, which could compromise
21 the security of the system.
26 - **DCE-Preamble**: The DCE Preamble prepares the platform for DRTM by
[all …]
|
| /rk3399_ARM-atf/docs/plat/ |
| H A D | rpi3.rst | 7 The following instructions explain how to use this port of the TF-A with the
8 default distribution of `Raspbian`_ because that's the distribution officially
9 supported by the Raspberry Pi Foundation. At the moment of writing this, the
12 the Foundation can be compiled for AArch64 by following the steps in
15 **IMPORTANT NOTE**: This port isn't secure. All of the memory used is DRAM,
16 which is available from both the Non-secure and Secure worlds. This port
18 elements like PSCI to support the Linux kernel.
23 The SoC used by the Raspberry Pi 3 is the Broadcom BCM2837. It is a SoC with a
24 VideoCore IV that acts as primary processor (and loads everything from the SD
25 card) and is located between all Arm cores and the DRAM. Check the `Raspberry Pi
[all …]
|
| H A D | socionext-uniphier.rst | 4 Socionext UniPhier Armv8-A SoCs use Trusted Firmware-A (TF-A) as the secure
8 image from a non-volatile storage to the on-chip SRAM, and jumps over to it.
11 problem is BL2 does not fit in the 64KB limit if
14 `UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the DRAM,
15 expands BL2 there, and hands the control over to it. Therefore, all images
18 The UniPhier platform works with/without TBB. See below for the build process
19 of each case. The image authentication for the UniPhier platform fully
20 complies with the Trusted Board Boot Requirements (TBBR) specification.
22 The UniPhier BL does not implement the authentication functionality, that is,
23 it can not verify the BL2 image by itself. Instead, the UniPhier BL assures
[all …]
|
| /rk3399_ARM-atf/docs/getting_started/ |
| H A D | rt-svc-writers-guide.rst | 7 This document describes how to add a runtime service to the EL3 Runtime
10 Software executing in the normal world and in the trusted world at exception
11 levels lower than EL3 will request runtime services using the Secure Monitor
12 Call (SMC) instruction. These requests will follow the convention described in
13 the SMC Calling Convention PDD (`SMCCC`_). The `SMCCC`_ assigns function
17 SMC Functions are grouped together based on the implementor of the service, for
18 example a subset of the Function IDs are designated as "OEM Calls" (see `SMCCC`_
19 for full details). The EL3 runtime services framework in BL31 enables the
21 into the BL31 image. This simplifies the integration of common software from
24 dispatched to their respective service implementation - the
[all …]
|
| /rk3399_ARM-atf/docs/security_advisories/ |
| H A D | security-advisory-tfv-8.rst | 26 When taking an exception to EL3, BL31 saves the CPU context. The aim is to
27 restore it before returning into the lower exception level software that called
28 into the firmware. However, for an SMC exception, the general purpose registers
29 ``x0`` to ``x3`` are not part of the CPU context saved on the stack.
31 As per the `SMC Calling Convention`_, up to 4 values may be returned to the
33 into the CPU context, typically using one of the ``SMC_RETx()`` macros provided
34 in the ``include/lib/aarch64/smccc_helpers.h`` header file.
36 Before returning to the caller, the ``restore_gp_registers()`` function is
37 called. It restores the values of all general purpose registers taken from the
38 CPU context stored on the stack. This includes registers ``x0`` to ``x3``, as
[all …]
|
| /rk3399_ARM-atf/docs/plat/arm/ |
| H A D | arm-build-options.rst | 8 DRAM. By default, BL31 is in the secure SRAM. Set this flag to 1 to load
10 sets the TSP location to DRAM and ignores the ``ARM_TSP_RAM_LOCATION`` build
13 - ``ARM_CONFIG_CNTACR``: boolean option to unlock access to the ``CNTBase<N>``
14 frame registers by setting the ``CNTCTLBase.CNTACR<N>`` register bits. The
16 should match the frame used by the Non-Secure image (normally the Linux
17 kernel). Default is true (access to the frame is allowed).
19 - ``ARM_FW_CONFIG_LOAD_ENABLE``: Boolean option to enable the loading of
20 FW_CONFIG device trees from the Firmware Image Package (FIP). When enabled,
21 BL2 calls the platform specific function `arm_bl2_el3_plat_config_load`.
22 This function is responsible for loading, parsing, and validating the
[all …]
|