mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-17 18:14:24 +00:00
56b741d3e4
This chain of trust is targeted at Arm CCA solutions and defines 3 independent 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 components running on the CCA platform. The CCA signing domain might be independent from other signing domains providing other firmware blobs. The CCA platform is a collective term used to identify all hardware and firmware components involved in delivering the CCA security guarantee. Hence, all hardware and firmware components on a CCA enabled system that a Realm is required to trust. In the context of TF-A, this corresponds to BL1, BL2, BL31, RMM and associated configuration files. The CCA signing domain is rooted in the Silicon ROTPK, just as in the TBBR CoT. 2) Non-CCA Secure World signing domain. This includes SPMC (and associated configuration file) as the expected BL32 image as well as SiP-owned secure partitions. It is rooted in a new SiP-owned key called Secure World ROTPK, or SWD_ROTPK for short. 3) Platform owner signing domain. This includes BL33 (and associated configuration file) and the platform owner's secure partitions. It is rooted in the Platform ROTPK, or PROTPK. [1] https://developer.arm.com/documentation/DEN0096/A_a Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com> Change-Id: I6ffef3f53d710e6a2072fb4374401249122a2805 |
||
|---|---|---|
| .. | ||
| common | ||
| drivers | ||
| lib | ||
| plat | ||
| README | ||
All headers under include/export/ are export headers that are intended for inclusion in third-party code which needs to interact with TF-A data structures or interfaces. They must follow these special rules: - Header guards should start with ARM_TRUSTED_FIRMWARE_ to reduce clash risk. - All definitions should be sufficiently namespaced (e.g. with BL_ or TF_) to make name clashes with third-party code unlikely. - They must not #include any headers except other export headers, and those includes must use relative paths with "../double_quotes.h" notation. - They must not rely on any type definitions other that <stdint.h> types defined in the ISO C standard (i.e. uint64_t is fine, but not u_register_t). They should still not #include <stdint.h>. Instead, wrapper headers including export headers need to ensure that they #include <stdint.h> earlier in their include order. - They must not rely on any macro definitions other than those which are pre-defined by all common compilers (e.g. __ASSEMBLER__ or __aarch64__). - They must only contain macro, type and structure definitions, no prototypes. - They should avoid using integer types with architecture-dependent widths (e.g. long, uintptr_t, pointer types) where possible. (Some existing export headers are violating this for now.) - Their names should always end in "_exp.h". - Normal TF-A code should never include export headers directly. Instead, it should include a wrapper header that ensures the export header is included in the right manner. (The wrapper header for include/export/x/y/z_exp.h should normally be placed at include/x/y/z.h.)