arm-trusted-firmware/include/export
Louis Mayencourt 243875eaf9 tbbr/dualroot: Add fw_config image in chain of trust
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
2020-06-24 08:44:26 +01:00
..
common tbbr/dualroot: Add fw_config image in chain of trust 2020-06-24 08:44:26 +01:00
drivers Factor out cross-BL API into export headers suitable for 3rd party code 2019-07-23 20:25:34 -07:00
lib Unify type of "cpu_idx" across PSCI module. 2020-01-10 17:11:51 +00:00
plat mediatek: mt8183: pass platform parameters 2019-09-10 11:25:29 +08:00
README Factor out cross-BL API into export headers suitable for 3rd party code 2019-07-23 20:25:34 -07:00

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.)