feat(arm): remove the bl2 static c fileThere is no need for the bl2 static c file forCCA and Duaroot CoT, remove them from the repoChange-Id: I251d085034dae0f6b3c6cefdbb129a9e1dd0530bSigned-off
feat(arm): remove the bl2 static c fileThere is no need for the bl2 static c file forCCA and Duaroot CoT, remove them from the repoChange-Id: I251d085034dae0f6b3c6cefdbb129a9e1dd0530bSigned-off-by: Xialin Liu <Xialin.Liu@ARM.com>
show more ...
refactor(auth): separate bl1 and bl2 CoTSeparate the bl1 and bl2 CoT into individual C files for theupcoming tool, i.e. the CoT device tree-to-source file generator.Change-Id: I0d24791991b3539c7
refactor(auth): separate bl1 and bl2 CoTSeparate the bl1 and bl2 CoT into individual C files for theupcoming tool, i.e. the CoT device tree-to-source file generator.Change-Id: I0d24791991b3539c7aef9a562920dc62fecdc69aSigned-off-by: Xialin Liu <Xialin.Liu@ARM.com>
feat(auth): add CCA NV ctr to CCA CoTModifying the CCA CoT description to put the CCA content certificateunder the new CCA NV counter.Change-Id: Ib962cef5eaa15bb9ccce86012f21327d29d4adadSigned-
feat(auth): add CCA NV ctr to CCA CoTModifying the CCA CoT description to put the CCA content certificateunder the new CCA NV counter.Change-Id: Ib962cef5eaa15bb9ccce86012f21327d29d4adadSigned-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
refactor(mbedtls): avoid including MBEDTLS_CONFIG_FILECurrently we include MBEDTLS_CONFIG_FILE directly and if a customconfig file is used it will included.However from mbedtls-3.x onwards it di
refactor(mbedtls): avoid including MBEDTLS_CONFIG_FILECurrently we include MBEDTLS_CONFIG_FILE directly and if a customconfig file is used it will included.However from mbedtls-3.x onwards it discourages usage ofMBEDTLS_CONFIG_FILE include directly, so to resolve this and keep 2.28compatibility include version.h which would include the custom configfile if present and also would expose us with mbedtls-major-versionnumber which could be used for selecting features and functions formbedtls 2.28 or 3.3Change-Id: I029992311be2a38b588ebbb350875b03ea29acdbSigned-off-by: Govindraj Raja <govindraj.raja@arm.com>
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