| /rk3399_ARM-atf/docs/about/ |
| H A D | release-information.rst | 49 | v2.0 | 1st week of Oct '18 | 1st week of Sep '18 |
51 | v2.1 | 5th week of Mar '19 | 1st week of Mar '19 |
53 | v2.2 | 4th week of Oct '19 | 1st week of Oct '19 |
55 | v2.3 | 4th week of Apr '20 | 1st week of Apr '20 |
57 | v2.4 | 2nd week of Nov '20 | 4th week of Oct '20 |
59 | v2.5 | 3rd week of May '21 | 5th week of Apr '21 |
61 | v2.6 | 4th week of Nov '21 | 2nd week of Nov '21 |
63 | v2.7 | 5th week of May '22 | 3rd week of May '22 |
65 | v2.8 | 5th week of Nov '22 | 3rd week of Nov '22 |
67 | v2.9 | 4th week of May '23 | 2nd week of May '23 |
[all …]
|
| /rk3399_ARM-atf/licenses/ |
| H A D | LICENSE-APACHE-2.0.txt | 11 and distribution as defined by Sections 1 through 9 of this document.
16 "Legal Entity" shall mean the union of the acting entity and all
18 control with that entity. For the purposes of this definition,
20 direction or management of such entity, whether by contract or
21 otherwise, or (ii) ownership of fifty percent (50%) or more of the
22 outstanding shares, or (iii) beneficial ownership of such entity.
32 transformation or translation of a Source form, including but
36 "Work" shall mean the work of authorship, whether in Source or
44 represent, as a whole, an original work of authorship. For the purposes
45 of this License, Derivative Works shall not include works that remain
[all …]
|
| /rk3399_ARM-atf/lib/compiler-rt/ |
| H A D | LICENSE.TXT | 5 The compiler_rt library is dual licensed under both the University of Illinois
6 "BSD-Like" license and the MIT license. As a user of this code you may choose
10 Full text of the relevant licenses is included below.
14 University of Illinois/NCSA
25 University of Illinois at Urbana-Champaign
29 Permission is hereby granted, free of charge, to any person obtaining a copy of
33 of the Software, and to permit persons to whom the Software is furnished to do
36 * Redistributions of source code must retain the above copyright notice,
37 this list of conditions and the following disclaimers.
40 this list of conditions and the following disclaimers in the
[all …]
|
| /rk3399_ARM-atf/docs/plat/marvell/armada/misc/ |
| H A D | mvebu-ccu.rst | 6 The CCU node includes a description of the address decoding configuration.
12 Return the CCU windows configuration and the number of windows of the
19 Array that includes the configuration of the windows. Every window/entry is
22 - Base address of the window
23 - Size of the window
24 - Target-ID of the window
|
| H A D | mvebu-io-win.rst | 6 The IO WIN includes a description of the address decoding configuration.
9 layer of decoding. This additional address decoding layer defines one of the
23 Returns the IO windows configuration and the number of windows of the
30 Array that include the configuration of the windows. Every window/entry is
33 - Base address of the window
34 - Size of the window
35 - Target-ID of the window
|
| H A D | mvebu-iob.rst | 6 The IOB includes a description of the address decoding configuration.
9 When a transaction passes through the IOB, its address is compared to each of
17 Returns the IOB windows configuration and the number of windows
23 Array that includes the configuration of the windows. Every window/entry is
26 - Base address of the window
27 - Size of the window
28 - Target-ID of the window
|
| /rk3399_ARM-atf/docs/components/ |
| H A D | platform-interrupt-controller-API.rst | 5 abstracts the runtime configuration and control of interrupt controller from 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.
71 This API should return the *active* status of the interrupt ID specified by the
74 In case of Arm standard platforms using GIC, the implementation of the API reads
75 the GIC *Set Active Register* to read and return the active status of the
89 In case of Arm standard platforms using GIC, the implementation of the API
104 In case of Arm standard platforms using GIC, the implementation of the API
117 This API should set the priority of the interrupt specified by first parameter
[all …]
|
| H A D | ffa-manifest-binding.rst | 16 minor versions of the device tree binding for the FFA manifest represented
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
30 - Y is the minor version of FF-A expected by the partition at the FFA
35 - An array of comma separated tuples each consisting of 4 <u32> values,
36 identifying the UUID of the services implemented by this partition.
53 - Name of the partition e.g. for debugging purposes.
57 - Number of vCPUs that a VM or SP wants to instantiate.
59 - In the absence of virtualization, this is the number of execution
[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
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;
19 #. Support for dynamic mapping and unmapping of regions, even while the MMU is
26 #. Support for changing memory attributes of memory regions at run-time.
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
43 From this point onwards, this document will implicitly refer to version 2 of the
50 This section presents some of the key concepts and data structures used in the
[all …]
|
| H A D | secure-partition-manager-mm.rst | 20 fulfils the requirements of a security service as described above.
22 Management services are typically implemented at the highest level of privilege
35 Placement of management and security functions with diverse requirements in a
36 privileged Exception Level (i.e. EL3 or S-EL1) makes security auditing of
37 firmware more difficult and does not allow isolation of unrelated services from
48 under the control of privileged software, provides one or more services and
55 - A range of synchronous exceptions (e.g. SMC function identifiers).
64 The following diagram illustrates the place of a Secure Partition in a typical
96 Alternatively, a partition can be viewed as a thread of execution running under
97 the control of the SPM. Hence common programming concepts described below are
[all …]
|
| H A D | cot-binding.rst | 1 Chain of trust bindings
4 The device tree allows to describe the chain of trust with the help of
6 'manifests' and 'images' nodes contains number of sub-nodes (i.e. 'certificate'
7 and 'image' nodes) mentioning properties of the certificate and image respectively.
9 Also, device tree describes 'non-volatile-counters' node which contains number of
10 sub-nodes mentioning properties of all non-volatile-counters used in the chain of trust.
21 Description: Container of certificate nodes.
45 using root of trust public key.
62 as root-certificates are validated using root of trust
90 This property is used to refer one of the non-volatile
[all …]
|
| H A D | rmm-el3-comms-spec.rst | 25 compatibility with the register arguments passed as part of Boot Interface and
52 - ``RES0``: Bit 31 of the version number is reserved 0 as to maintain
53 consistency with the versioning schemes used in other parts of RMM.
55 This document specifies the 0.8 version of Boot Interface ABI and RMM-EL3
56 services specification and the 0.5 version of the Boot Manifest.
63 This section deals with the Boot Interface part of the specification.
65 One of the goals of the Boot Interface is to allow EL3 firmware to pass
69 images in the boot sequence and remain agnostic of any particular format used
72 The Boot Interface ABI defines a set of register conventions and
83 entered from EL3 as part of RMI handling.
[all …]
|
| /rk3399_ARM-atf/docs/design/ |
| H A D | trusted-board-boot.rst | 6 normal world bootloader. It does this by establishing a `Chain of Trust` using
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,
12 (FWU)` design document, which implements a specific aspect of the TBBR.
14 Chain of Trust
17 A Chain of Trust (CoT) starts with a set of implicitly trusted components, which
18 are used to establish trust in the next layer of components, and so on, in a
21 The chain of trust depends on several factors, including:
23 - The set of firmware images in use on this platform.
24 Typically, most platforms share a common set of firmware images (BL1, BL2,
[all …]
|
| H A D | psci-pd-tree.rst | 9 populate a tree that describes the hierarchy of power domains in the
19 code is not scalable. The use of an MPIDR also restricts the number of
22 Therefore, there is a need to decouple allocation of MPIDRs from the
25 #. The current arrangement of the power domain tree requires a binary search
36 #. The attributes of a core power domain differ from the attributes of power
55 removed. A platform must define an array of unsigned chars such that:
57 #. The first entry in the array specifies the number of power domains at the
63 of power domains that are its direct children.
65 #. The size of the array minus the first entry will be equal to the number of
68 #. The value in each entry in the array is used to find the number of entries
[all …]
|
| /rk3399_ARM-atf/docs/plat/arm/fvp/ |
| H A D | fvp-support.rst | 4 An |FVP| provides a complete simulation of an Arm system. This is a generic term
5 used for all kinds of vastly different and incompatible systems. One category of
6 these systems are the ``FVP_Base`` family of FVPs. These are entirely virtual
8 degrees of customisation but share a lot of similarities. The ``fvp`` platform
12 Please refer to each FVP's documentation for a detailed description of the model
15 The latest version of the AArch64 build of TF-A has been tested on the following
53 The latest version of the AArch32 build of TF-A has been tested on the
66 The *Foundation* and *Base* FVPs can be downloaded free of charge. See the
67 `Arm's website`_ for download options of all FVPs.
81 The software will not work on Version 1.0 of the Foundation FVP.
[all …]
|
| /rk3399_ARM-atf/docs/security_advisories/ |
| H A D | security-advisory-tfv-10.rst | 5 | Title | Incorrect validation of X.509 certificate extensions can |
6 | | result in an out-of-bounds read. |
16 | Affected | downstream usages of ``get_ext()`` and/or ``auth_nvctr()`` |
19 | Impact | Out-of-bounds read. |
30 | | - `abb8f936fd0ad085`_ "fix(auth): avoid out-of-bounds read |
42 certificate to cause an out-of-bounds memory read.
46 different context than seen in upstream code. Details of such context is
47 described in the rest of this document.
55 - `ITU-T X.690`_, *ASN.1 encoding rules: Specification of Basic Encoding Rules
64 not check the return value of the various ``mbedtls_*()`` functions, as
[all …]
|
| H A D | security-advisory-tfv-7.rst | 20 | Impact | Leakage of secure world data to normal world |
27 This security advisory describes the current understanding of the Trusted
28 Firmware-A (TF-A) exposure to Variant 4 of the cache speculation vulnerabilities
30 impact of these vulnerabilities on Arm systems, please refer to the `Arm
33 At the time of writing, the TF-A project is not aware of a Variant 4 exploit
35 exploit against current standard configurations of TF-A, due to the limited
37 is becoming increasingly difficult to guarantee with the introduction of complex
39 (SDEI)`_. Also, the TF-A project does not have visibility of all
43 control bit to prevent the re-ordering of stores and loads.
45 For each affected CPU type, TF-A implements one of the two following mitigation
[all …]
|
| /rk3399_ARM-atf/docs/threat_model/firmware_threat_model/ |
| H A D | index.rst | 5 platform's needs, providing a holistic threat model covering all of its features
6 is not necessarily the best approach. Instead, we provide a collection of
14 current status of the code from a security standpoint.
23 often tagged as experimental for some period of time. Such experimental
26 of scope of TF-A's threat model. See :ref:`Experimental features
29 Each of these documents give a description of the target of evaluation using a
30 data flow diagram, as well as a list of threats we have identified using the
|
| H A D | threat_model.rst | 10 .. _Target of Evaluation:
13 Target of Evaluation
16 In this threat model, the target of evaluation is the Trusted
19 shown on Figure 1. Everything else on Figure 1 is outside of the scope of
39 The :ref:`Threat Model for TF-A with Arm CCA support` covers these types of
52 shows a model of the different components of a TF-A-based system and
53 their interactions with TF-A. A description of each diagram element
55 trust boundaries. Components outside of the broken lines
78 | | to registers and memory of TF-A. |
102 In this section we identify and provide assessment of potential threats to TF-A
[all …]
|
| H A D | threat_model_fw_update_and_recovery.rst | 7 This document provides a threat model of TF-A firmware for platforms with
9 To understand the design of the firmware update refer
13 Model` in a number of places, as some of the contents are applicable to this
16 Target of Evaluation
19 In this threat model, the target of evaluation is the Trusted Firmware for
36 of this threat model. Only additional details are pointed out.
59 outside of TF-A security boundary or for a physical attacker to modify it
60 in order to change the behaviour of the FWU process.
65 tries to modify it to prevent the execution of the updated firmware.
69 intention of preventing the anti-rollback update.
[all …]
|
| /rk3399_ARM-atf/docs/design_documents/ |
| H A D | drtm_poc.rst | 1 DRTM Proof of Concept
4 Dynamic Root of Trust for Measurement (DRTM) begins a new trust environment
6 and formal definition of DRTM for Arm-based systems are detailed in the
9 Static Root of Trust for Measurement (SRTM)/Measured Boot implementation,
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.
31 - **D-CRTM**: The D-CRTM is the trust anchor (or root of trust) for the
35 stage of DRTM, the DCE. The D-CRTM measures the DCE, verifies its
39 system’s state, measures security-critical attributes of the system,
[all …]
|
| /rk3399_ARM-atf/docs/threat_model/ |
| H A D | supply_chain_threat_model.rst | 16 project through other piece of code or packages the project depends on. This
25 This document provides analysis of software supply chain attack threats for the
32 A brief description of each component is provided below.
42 Tree Binary (DTB) files. It is part of the Device Tree Compiler (DTC)
43 toolchain [1]_. DTC is used as part of the build process on the host machine
48 - *compiler-rt*: This is a collection of runtime libraries from the LLVM
73 These are software components that are not part of the TF-A repository but are
83 The following table lists TF-A dependencies including the sources of the
89 | Dependency | Location of Dependency | Original Source |
106 description of each component and where they are sourced from.
[all …]
|
| /rk3399_ARM-atf/docs/process/ |
| H A D | security.rst | 8 relevant to Trusted Firmware-A. We encourage responsible disclosure of
11 We disclose TF-A vulnerabilities as Security Advisories, all of which are listed
12 at the bottom of this page. Any new ones will, additionally, be announced on the
18 Although we try to keep TF-A secure, we can only do so with the help of the
19 community of developers and security researchers.
26 One of the goals of this process is to ensure providers of products that use
27 TF-A have a chance to consider the implications of the vulnerability and its
46 | |TFV-1| | Malformed Firmware Update SMC can result in copy of unexpectedly |
55 | | authentication of unexpected data in secure memory in AArch32 |
73 | |TFV-10| | Incorrect validation of X.509 certificate extensions can result |
[all …]
|
| /rk3399_ARM-atf/docs/plat/ |
| H A D | xilinx-versal-net.rst | 5 The platform only uses the runtime part of TF-A as Xilinx Versal NET already
35 * `VERSAL_NET_ATF_MEM_BASE`: Specifies the base address of the bl31 binary.
36 * `VERSAL_NET_ATF_MEM_SIZE`: Specifies the size of the memory region of the bl31 binary.
37 * `VERSAL_NET_BL32_MEM_BASE`: Specifies the base address of the bl32 binary.
38 * `VERSAL_NET_BL32_MEM_SIZE`: Specifies the size of the memory region of the bl32 binary.
65 Allocated subranges of Function Identifier to SIP services
98 | 0xc2000FFF | Fast SMC64 SiP Service call used for pass-through of AMD-Xilinx Platf…
114 Call UID Query – Returns a unique identifier of the service provider.
116 Revision Query – Returns revision details of the service implementor.
|
| /rk3399_ARM-atf/plat/arm/board/neoverse_rd/platform/rdn2/fdts/ |
| H A D | rdn2_nt_fw_config.dts | 14 * value of platform-id and config-id will be set to the
15 * correct values during the BL2 stage of boot.
22 * First cell pair: Count of isolated CPUs in the list.
23 * Rest of the cells: MPID list of the isolated CPUs.
|