feat(tbbr): add image id for backup GPTAdd image identifier to access backup-GPT header and entry,when we fail to get primary GPT header.Currently we use only the primary gpt header, But we plan
feat(tbbr): add image id for backup GPTAdd image identifier to access backup-GPT header and entry,when we fail to get primary GPT header.Currently we use only the primary gpt header, But we plan touse backup GPT header in case our primary GPT header failsverification or is corrupted.Change-Id: I12eedd5d2a5cda21c64254d461d09d400d4edb30Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
show more ...
feat(cca): introduce new "cca" chain of trustThis chain of trust is targeted at Arm CCA solutions and defines 3independent signing domains:1) CCA signing domain. The Arm CCA Security Model (Arm
feat(cca): introduce new "cca" chain of trustThis chain of trust is targeted at Arm CCA solutions and defines 3independent signing domains:1) CCA signing domain. The Arm CCA Security Model (Arm DEN-0096.A.a) [1]refers to the CCA signing domain as the provider of CCA componentsrunning on the CCA platform. The CCA signing domain might be independentfrom other signing domains providing other firmware blobs.The CCA platform is a collective term used to identify all hardware andfirmware components involved in delivering the CCA security guarantee.Hence, all hardware and firmware components on a CCA enabled system thata Realm is required to trust.In the context of TF-A, this corresponds to BL1, BL2, BL31, RMM andassociated configuration files.The CCA signing domain is rooted in the Silicon ROTPK, just as in theTBBR CoT.2) Non-CCA Secure World signing domain. This includes SPMC (andassociated configuration file) as the expected BL32 image as well asSiP-owned secure partitions. It is rooted in a new SiP-owned key calledSecure World ROTPK, or SWD_ROTPK for short.3) Platform owner signing domain. This includes BL33 (and associatedconfiguration file) and the platform owner's secure partitions. It isrooted in the Platform ROTPK, or PROTPK.[1] https://developer.arm.com/documentation/DEN0096/A_aSigned-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>Change-Id: I6ffef3f53d710e6a2072fb4374401249122a2805
feat(rme): add ENABLE_RME build option and support for RMM imageThe changes include:- A new build option (ENABLE_RME) to enable FEAT_RME- New image called RMM. RMM is R-EL2 firmware that manage
feat(rme): add ENABLE_RME build option and support for RMM imageThe changes include:- A new build option (ENABLE_RME) to enable FEAT_RME- New image called RMM. RMM is R-EL2 firmware that manages Realms. When building TF-A, a path to RMM image can be specified using the "RMM" build flag. If RMM image is not provided, TRP is built by default and used as RMM image.- Support for RMM image in fiptoolSigned-off-by: Zelalem Aweke <zelalem.aweke@arm.com>Change-Id: I017c23ef02e465a5198baafd665a60858ecd1b25
feat(fwu): add FWU driverImplemented FWU metadata load and verification APIs.Also, exported below APIs to the platform:1. fwu_init - Load FWU metadata in a structure. Also, set the address
feat(fwu): add FWU driverImplemented FWU metadata load and verification APIs.Also, exported below APIs to the platform:1. fwu_init - Load FWU metadata in a structure. Also, set the addresses of updated components in I/O policy2. fwu_is_trial_run_state - To detect trial run or regular run stateChange-Id: I67eeabb52d9275ac83be635306997b7c353727cdSigned-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
tbbr/dualroot: Add fw_config image in chain of trustfw_config image is authenticated using secure boot framework byadding it into the single root and dual root chain of trust.The COT for fw_conf
tbbr/dualroot: Add fw_config image in chain of trustfw_config image is authenticated using secure boot framework byadding 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
dualroot: add chain of trust for secure partitionsA new certificate "sip-sp-cert" has been added for Silicon Provider(SiP)owned Secure Partitions(SP). A similar support for Platform owned SP canb
dualroot: add chain of trust for secure partitionsA new certificate "sip-sp-cert" has been added for Silicon Provider(SiP)owned Secure Partitions(SP). A similar support for Platform owned SP canbe 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 providedin dualroot.Secure Partition content certificate is assigned image ID 31 and SPimages 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
TBB: Add an IO abstraction layer to load encrypted firmwaresTBBR spec advocates for optional encryption of firmwares (see optionalrequirement: R060_TBBR_FUNCTION). So add an IO abstaction layer to
TBB: Add an IO abstraction layer to load encrypted firmwaresTBBR spec advocates for optional encryption of firmwares (see optionalrequirement: R060_TBBR_FUNCTION). So add an IO abstaction layer tosupport firmware decryption that can be stacked above any underlying IO/packaging layer like FIP etc. It aims to provide a framework to load anyencrypted IO payload.Also, add plat_get_enc_key_info() to be implemented in a platformspecific manner as handling of encryption key may vary from one platformto another.Signed-off-by: Sumit Garg <sumit.garg@linaro.org>Change-Id: I9892e0ddf00ebecb8981301dbfa41ea23e078b03
fconf: Add Secure Partitions information as propertyUse the firmware configuration framework to retrieve information aboutSecure Partitions to facilitate loading them into memory.To load a SP im
fconf: Add Secure Partitions information as propertyUse the firmware configuration framework to retrieve information aboutSecure Partitions to facilitate loading them into memory.To load a SP image we need UUID look-up into FIP and the load addresswhere it needs to be loaded in memory.This patch introduces a SP populator function which gets UUID and loadaddress from firmware config device tree and updates its C datastructure.Change-Id: I17faec41803df9a76712dcc8b67cadb1c9daf8cdSigned-off-by: Olivier Deprez <olivier.deprez@arm.com>Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Factor out cross-BL API into export headers suitable for 3rd party codeThis patch adds a new include/export/ directory meant for inclusion inthird-party code. This is useful for cases where third-
Factor out cross-BL API into export headers suitable for 3rd party codeThis patch adds a new include/export/ directory meant for inclusion inthird-party code. This is useful for cases where third-party code needsto interact with TF-A interfaces and data structures (such as a customBL2-implementation like coreboot handing off to BL31). Directlyincluding headers from the TF-A repository avoids having to duplicateall these definitions (and risk them going stale), but with the currentheader structure this is not possible because handoff API definitionsare too deeply intertwined with other TF code/headers and chain-includeother headers that will not be available in the other environment.The new approach aims to solve this by separating only the parts thatare really needed into these special headers that are self-contained andwill not chain-include other (non-export) headers. TF-A code shouldnever include them directly but should instead always include therespective wrapper header, which will include the required prerequisites(like <stdint.h>) before including the export header. Third-party codecan include the export headers via its own wrappers that make sure thenecessary definitions are available in whatever way that environment canprovide them.Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43abSigned-off-by: Julius Werner <jwerner@chromium.org>