- 12 Oct, 2020 1 commit
-
-
Jimmy Brisson authored
Usually, C has no problem up-converting types to larger bit sizes. MISRA rule 10.7 requires that you not do this, or be very explicit about this. This resolves the following required rule: bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None> The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U | 0x3c0U" (32 bits) is less that the right hand operand "18446744073709547519ULL" (64 bits). This also resolves MISRA defects such as: bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)] In the expression "3U << 20", shifting more than 7 bits, the number of bits in the essential type of the left expression, "3U", is not allowed. Further, MISRA requires that all shifts don't overflow. The definition of PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues. This fixes the violation by changing the definition to 1UL << 12. Since this uses 32bits, it should not create any issues for aarch32. This patch also contains a fix for a build failure in the sun50i_a64 platform. Specifically, these misra fixes removed a single and instruction, 92407e73 and x19, x19, #0xffffffff from the cm_setup_context function caused a relocation in psci_cpus_on_start to require a linker-generated stub. This increased the size of the .text section and caused an alignment later on to go over a page boundary and round up to the end of RAM before placing the .data section. This sectionn is of non-zero size and therefore causes a link error. The fix included in this reorders the functions during link time without changing their ording with respect to alignment. Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
- 24 Jun, 2020 1 commit
-
-
Louis Mayencourt authored
fw_config image is authenticated using secure boot framework by adding it into the single root and dual root chain of trust. The COT for fw_config image looks as below: +------------------+ +-------------------+ | ROTPK/ROTPK Hash |------>| Trusted Boot fw | +------------------+ | Certificate | | (Auth Image) | /+-------------------+ / | / | / | / | L v +------------------+ +-------------------+ | fw_config hash |------>| fw_config | | | | (Data Image) | +------------------+ +-------------------+ Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com> Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I08fc8ee95c29a95bb140c807dd06e772474c7367
-
- 09 Jun, 2020 1 commit
-
-
Manish Pandey authored
A new certificate "sip-sp-cert" has been added for Silicon Provider(SiP) owned Secure Partitions(SP). A similar support for Platform owned SP can be added in future. The certificate is also protected against anti- rollback using the trusted Non-Volatile counter. To avoid deviating from TBBR spec, support for SP CoT is only provided in dualroot. Secure Partition content certificate is assigned image ID 31 and SP images follows after it. The CoT for secure partition look like below. +------------------+ +-------------------+ | ROTPK/ROTPK Hash |------>| Trusted Key | +------------------+ | Certificate | | (Auth Image) | /+-------------------+ / | / | / | / | L v +------------------+ +-------------------+ | Trusted World |------>| SiP owned SPs | | Public Key | | Content Cert | +------------------+ | (Auth Image) | / +-------------------+ / | / v| +------------------+ L +-------------------+ | SP_PKG1 Hash |------>| SP_PKG1 | | | | (Data Image) | +------------------+ +-------------------+ . . . . . . +------------------+ +-------------------+ | SP_PKG8 Hash |------>| SP_PKG8 | | | | (Data Image) | +------------------+ +-------------------+ Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: Ia31546bac1327a3e0b5d37e8b99c808442d5e53f
-
- 06 Mar, 2020 1 commit
-
-
Sumit Garg authored
TBBR spec advocates for optional encryption of firmwares (see optional requirement: R060_TBBR_FUNCTION). So add an IO abstaction layer to support firmware decryption that can be stacked above any underlying IO/ packaging layer like FIP etc. It aims to provide a framework to load any encrypted IO payload. Also, add plat_get_enc_key_info() to be implemented in a platform specific manner as handling of encryption key may vary from one platform to another. Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Change-Id: I9892e0ddf00ebecb8981301dbfa41ea23e078b03
-
- 03 Mar, 2020 1 commit
-
-
Olivier Deprez authored
Use the firmware configuration framework to retrieve information about Secure Partitions to facilitate loading them into memory. To load a SP image we need UUID look-up into FIP and the load address where it needs to be loaded in memory. This patch introduces a SP populator function which gets UUID and load address from firmware config device tree and updates its C data structure. Change-Id: I17faec41803df9a76712dcc8b67cadb1c9daf8cd Signed-off-by: Olivier Deprez <olivier.deprez@arm.com> Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
-
- 24 Jul, 2019 1 commit
-
-
Julius Werner authored
This patch adds a new include/export/ directory meant for inclusion in third-party code. This is useful for cases where third-party code needs to interact with TF-A interfaces and data structures (such as a custom BL2-implementation like coreboot handing off to BL31). Directly including headers from the TF-A repository avoids having to duplicate all these definitions (and risk them going stale), but with the current header structure this is not possible because handoff API definitions are too deeply intertwined with other TF code/headers and chain-include other headers that will not be available in the other environment. The new approach aims to solve this by separating only the parts that are really needed into these special headers that are self-contained and will not chain-include other (non-export) headers. TF-A code should never include them directly but should instead always include the respective wrapper header, which will include the required prerequisites (like <stdint.h>) before including the export header. Third-party code can include the export headers via its own wrappers that make sure the necessary definitions are available in whatever way that environment can provide them. Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab Signed-off-by: Julius Werner <jwerner@chromium.org>
-