Commit graph

16 commits

Author SHA1 Message Date
Govindraj Raja
4c700c1563 chore: update to use Arm word across TF-A
Align entire TF-A to use Arm in copyright header.

Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
2023-08-08 15:12:30 +01:00
Akshay Belsare
1a56ed4b35 fix: integer suffix macro definition
The current implementation of macro L/LL/UL/ULL concatenates the input
with "L"/"LL"/"UL"/"ULL" respectively.
In the case where a macro is passed to L/LL/UL/ULL as input,
the input macro name is concatenated with, rather than expanding
the input macro and then concatenating it.
The implementation of L/LL/UL/ULL is modified to two level macro,
so as to concatenate to the expansion of a macro argument.

Change 5b33ad174a "Unify type of "cpu_idx" across PSCI module."
has modified the implementation of U() to two level macros without
changing the implementation of other macros.

Change-Id: Ie93d67dff5ce96223a3faf6c98b98fcda530fc34
Signed-off-by: Akshay Belsare <akshay.belsare@amd.com>
2023-06-20 15:22:19 +02:00
Jorge Troncoso
b0f473f500 chore: use tabs for indentation
This patch changes the definition of image_info_t to follow the TF-A
coding style documented at
https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-style.html

Signed-off-by: Jorge Troncoso <jatron@google.com>
Change-Id: I17af22b4ba60b41cf0b5fa84ac47beeb1536edcc
2022-09-12 15:12:01 -07:00
laurenw-arm
56b741d3e4 feat(cca): introduce new "cca" chain of trust
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
2022-06-14 09:47:37 -05:00
Jona Stubbe
9565962c37 refactor(plat/rockchip/rk3399/drivers/gpio): reduce code duplication
Refactor the GPIO code to use a small lookup table instead of redundant or
repetitive code.

Signed-off-by: Jona Stubbe <tf-a@jona-stubbe.de>
Change-Id: Icf60385095efc1f506e4215d497b60f90e16edfd
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2022-01-04 15:26:43 +01:00
Zelalem Aweke
5b18de09e8 feat(rme): add ENABLE_RME build option and support for RMM image
The 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 fiptool

Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I017c23ef02e465a5198baafd665a60858ecd1b25
2021-10-05 11:49:59 -05:00
Zelalem Aweke
4693ff7225 feat(rme): add Realm security state definition
FEAT_RME introduces two additional security states,
Root and Realm security states. This patch adds Realm
security state awareness to SMCCC helpers and entry point info
structure.

Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I9cdefcc1aa71259b2de46e5fb62b28d658fa59bd
2021-10-01 16:54:44 -05:00
Manish V Badarkhe
0ec3ac60d8 feat(fwu): add FWU driver
Implemented 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 policy
2. fwu_is_trial_run_state - To detect trial run or regular run
			    state

Change-Id: I67eeabb52d9275ac83be635306997b7c353727cd
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
2021-08-02 17:15:40 +01:00
Jimmy Brisson
d7b5f40823 Increase type widths to satisfy width requirements
Usually, C has no problem up-converting types to larger bit sizes. MISRA
rule 10.7 requires that you not do this, or be very explicit about this.
This resolves the following required rule:

    bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None>
    The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U |
    0x3c0U" (32 bits) is less that the right hand operand
    "18446744073709547519ULL" (64 bits).

This also resolves MISRA defects such as:

    bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)]
    In the expression "3U << 20", shifting more than 7 bits, the number
    of bits in the essential type of the left expression, "3U", is
    not allowed.

Further, MISRA requires that all shifts don't overflow. The definition of
PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues.
This fixes the violation by changing the definition to 1UL << 12. Since
this uses 32bits, it should not create any issues for aarch32.

This patch also contains a fix for a build failure in the sun50i_a64
platform. Specifically, these misra fixes removed a single and
instruction,

    92407e73        and     x19, x19, #0xffffffff

from the cm_setup_context function caused a relocation in
psci_cpus_on_start to require a linker-generated stub. This increased the
size of the .text section and caused an alignment later on to go over a
page boundary and round up to the end of RAM before placing the .data
section. This sectionn is of non-zero size and therefore causes a link
error.

The fix included in this reorders the functions during link time
without changing their ording with respect to alignment.

Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
2020-10-12 10:55:03 -05:00
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
Manish Pandey
44f1aa8efe dualroot: add chain of trust for secure partitions
A new certificate "sip-sp-cert" has been added for Silicon Provider(SiP)
owned Secure Partitions(SP). A similar support for Platform owned SP can
be 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 provided
in dualroot.
Secure Partition content certificate is assigned image ID 31 and SP
images 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
2020-06-09 16:22:26 +01:00
Sumit Garg
2be57b8658 TBB: Add an IO abstraction layer to load encrypted firmwares
TBBR spec advocates for optional encryption of firmwares (see optional
requirement: R060_TBBR_FUNCTION). So add an IO abstaction layer to
support firmware decryption that can be stacked above any underlying IO/
packaging layer like FIP etc. It aims to provide a framework to load any
encrypted IO payload.

Also, add plat_get_enc_key_info() to be implemented in a platform
specific manner as handling of encryption key may vary from one platform
to another.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Change-Id: I9892e0ddf00ebecb8981301dbfa41ea23e078b03
2020-03-06 16:40:37 +05:30
Olivier Deprez
7cd64d19c9 fconf: Add Secure Partitions information as property
Use the firmware configuration framework to retrieve information about
Secure Partitions to facilitate loading them into memory.

To load a SP image we need UUID look-up into FIP and the load address
where it needs to be loaded in memory.

This patch introduces a SP populator function which gets UUID and load
address from firmware config device tree and updates its C data
structure.

Change-Id: I17faec41803df9a76712dcc8b67cadb1c9daf8cd
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
2020-03-03 10:59:17 +00:00
Deepika Bhavnani
5b33ad174a Unify type of "cpu_idx" across PSCI module.
NOTE for platform integrators:
   API `plat_psci_stat_get_residency()` third argument
   `last_cpu_idx` is changed from "signed int" to the
   "unsigned int" type.

Issue / Trouble points
1. cpu_idx is used as mix of `unsigned int` and `signed int` in code
with typecasting at some places leading to coverity issues.

2. Underlying platform API's return cpu_idx as `unsigned int`
and comparison is performed with platform specific defines
`PLAFORM_xxx` which is not consistent

Misra Rule 10.4:
The value of a complex expression of integer type may only be cast to
a type that is narrower and of the same signedness as the underlying
type of the expression.

Based on above points, cpu_idx is kept as `unsigned int` to match
the API's and low-level functions and platform defines are updated
where ever required

Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com>
Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c
2020-01-10 17:11:51 +00:00
kenny liang
a561205724 mediatek: mt8183: pass platform parameters
Add plat parameter structs to support BL2 to pass
variable-length, variable-type parameters to BL31.
The parameters are structured as a link list.
During BL31 setup time, we traverse the list to process
each parameter.

Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: Ie84cfc9606656fb1d2780a68cadf27e09afa6628
2019-09-10 11:25:29 +08:00
Julius Werner
57bf605772 Factor out cross-BL API into export headers suitable for 3rd party code
This patch adds a new include/export/ directory meant for inclusion in
third-party code. This is useful for cases where third-party code needs
to interact with TF-A interfaces and data structures (such as a custom
BL2-implementation like coreboot handing off to BL31). Directly
including headers from the TF-A repository avoids having to duplicate
all these definitions (and risk them going stale), but with the current
header structure this is not possible because handoff API definitions
are too deeply intertwined with other TF code/headers and chain-include
other headers that will not be available in the other environment.

The new approach aims to solve this by separating only the parts that
are really needed into these special headers that are self-contained and
will not chain-include other (non-export) headers. TF-A code should
never include them directly but should instead always include the
respective wrapper header, which will include the required prerequisites
(like <stdint.h>) before including the export header. Third-party code
can include the export headers via its own wrappers that make sure the
necessary definitions are available in whatever way that environment can
provide them.

Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab
Signed-off-by: Julius Werner <jwerner@chromium.org>
2019-07-23 20:25:34 -07:00