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>
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>
refactor(mbedtls): allow platform to specify their config fileCommon mbedTLS implementation include the fixed configurationfile of mbedTLS and that does not gives flexilibility to theplatform to
refactor(mbedtls): allow platform to specify their config fileCommon mbedTLS implementation include the fixed configurationfile of mbedTLS and that does not gives flexilibility to theplatform to include their own mbedTLS configuration.Hence changes are done so that platform can include their ownmbedTLS configuration file.Signed-off-by: Lucian Paul-Trifu <lucian.paul-trifu@arm.com>Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>Change-Id: I04546589f67299e26b0a6a6e151cdf1fdb302607
dualroot: add chain of trust for Platform owned SPsFor dualroot CoT there are two sets of SP certificates, one owned bySilicon Provider(SiP) and other owned by Platform. Each certificate canhave
dualroot: add chain of trust for Platform owned SPsFor dualroot CoT there are two sets of SP certificates, one owned bySilicon Provider(SiP) and other owned by Platform. Each certificate canhave a maximum of 4 SPs.This patch reduces the number of SiP owned SPs from 8 to 4 and addsthe remaining 4 to Plat owned SP.Plat owned SP certificate is signed using Platform RoT key andprotected against anti-rollback using the Non-trusted Non-volatilecounter.Change-Id: Idc3ddd87d6d85a5506a7435f45a6ec17c4c50425Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
tbbr/dualroot: rename SP package certificate fileCurrently only single signing domain is supported for SP packages butthere is plan to support dual signing domains if CoT is dualroot.SP_CONTENT_
tbbr/dualroot: rename SP package certificate fileCurrently only single signing domain is supported for SP packages butthere is plan to support dual signing domains if CoT is dualroot.SP_CONTENT_CERT_ID is the certificate file which is currently generatedand signed with trusted world key which in-turn is derived from Siliconprovider RoT key.To allow dual signing domain for SP packages, other certificate filewill be derived from Platform owned RoT key.This patch renames "SP_CONTENT_CERT_ID" to "SIP_SP_CONTENT_CERT_ID" anddoes other related changes.Signed-off-by: Manish Pandey <manish.pandey2@arm.com>Change-Id: I0bc445a3ab257e2dac03faa64f46e36a9fed5e93
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
Cleanup the code for TBBR CoT descriptorsCoT used for BL1 and BL2 are moved to tbbr_cot_bl1.cand tbbr_cot_bl2.c respectively.Common CoT used across BL1 and BL2 are moved totbbr_cot_common.c.Si
Cleanup the code for TBBR CoT descriptorsCoT used for BL1 and BL2 are moved to tbbr_cot_bl1.cand tbbr_cot_bl2.c respectively.Common CoT used across BL1 and BL2 are moved totbbr_cot_common.c.Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>Change-Id: I2252ac8a6960b3431bcaafdb3ea4fb2d01b79cf5
Introduce a new "dualroot" chain of trustThis new chain of trust defines 2 independent signing domains:1) One for the silicon firmware (BL1, BL2, BL31) and optionally the Trusted OS. It is roo
Introduce a new "dualroot" chain of trustThis new chain of trust defines 2 independent signing domains:1) One for the silicon firmware (BL1, BL2, BL31) and optionally the Trusted OS. It is rooted in the Silicon ROTPK, just as in the TBBR CoT.2) One for the Normal World Bootloader (BL33). It is rooted in a new key called Platform ROTPK, or PROTPK for short.In terms of certificates chain,- Signing domain 1) is similar to what TBBR advocates (see page 21 of the TBBR specification), except that the Non-Trusted World Public Key has been removed from the Trusted Key Certificate.- Signing domain 2) only contains the Non-Trusted World Content certificate, which provides the hash of the Non-Trusted World Bootloader. Compared to the TBBR CoT, there's no Non-Trusted World Key certificate for simplicity.Change-Id: I62f1e952522d84470acc360cf5ee63e4c4b0b4d9Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>