Merge changes from topic "gpt_updates" into integration

* changes:
refactor(arm): use gpt_partition_init
feat(partition): add interface to init gpt
refactor(partition): convert warn to verbose

Merge changes from topic "gpt_updates" into integration

* changes:
refactor(arm): use gpt_partition_init
feat(partition): add interface to init gpt
refactor(partition): convert warn to verbose
feat(partition): add support to use backup GPT header
refactor(partition): get GPT header location from MBR
feat(arm): add IO policy to use backup gpt header
feat(tbbr): add image id for backup GPT

show more ...

feat(tbbr): add image id for backup GPT

Add image identifier to access backup-GPT header and entry,
when we fail to get primary GPT header.

Currently we use only the primary gpt header, But we plan

feat(tbbr): add image id for backup GPT

Add image identifier to access backup-GPT header and entry,
when we fail to get primary GPT header.

Currently we use only the primary gpt header, But we plan to
use backup GPT header in case our primary GPT header fails
verification or is corrupted.

Change-Id: I12eedd5d2a5cda21c64254d461d09d400d4edb30
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge changes from topic "lw/cca_cot" into integration

* changes:
feat(arm): retrieve the right ROTPK for cca
feat(arm): add support for cca CoT
feat(arm): provide some swd rotpk files
build

Merge changes from topic "lw/cca_cot" into integration

* changes:
feat(arm): retrieve the right ROTPK for cca
feat(arm): add support for cca CoT
feat(arm): provide some swd rotpk files
build(tbbr): drive cert_create changes for cca CoT
refactor(arm): add cca CoT certificates to fconf
feat(fiptool): add cca, core_swd, plat cert in FIP
feat(cert_create): define the cca chain of trust
feat(cca): introduce new "cca" chain of trust
build(changelog): add new scope for CCA
refactor(fvp): increase bl2 size when bl31 in DRAM

show more ...

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

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

show more ...

Merge changes from topic "za/feat_rme" into integration

* changes:
refactor(gpt): productize and refactor GPT library
feat(rme): disable Watchdog for Arm platforms if FEAT_RME enabled
docs(rme

Merge changes from topic "za/feat_rme" into integration

* changes:
refactor(gpt): productize and refactor GPT library
feat(rme): disable Watchdog for Arm platforms if FEAT_RME enabled
docs(rme): add build and run instructions for FEAT_RME
fix(plat/fvp): bump BL2 stack size
fix(plat/fvp): allow changing the kernel DTB load address
refactor(plat/arm): rename ARM_DTB_DRAM_NS region macros
refactor(plat/fvp): update FVP platform DTS for FEAT_RME
feat(plat/arm): add GPT initialization code for Arm platforms
feat(plat/fvp): add memory map for FVP platform for FEAT_RME
refactor(plat/arm): modify memory region attributes to account for FEAT_RME
feat(plat/fvp): add RMM image support for FVP platform
feat(rme): add GPT Library
feat(rme): add ENABLE_RME build option and support for RMM image
refactor(makefile): remove BL prefixes in build macros
feat(rme): add context management changes for FEAT_RME
feat(rme): add Test Realm Payload (TRP)
feat(rme): add RMM dispatcher (RMMD)
feat(rme): run BL2 in root world when FEAT_RME is enabled
feat(rme): add xlat table library changes for FEAT_RME
feat(rme): add Realm security state definition
feat(rme): add register definitions and helper functions for FEAT_RME

show more ...

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 manage

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

show more ...

Merge changes from topic "fw-update-2" into integration

* changes:
feat(sw_crc32): add software CRC32 support
refactor(hw_crc32): renamed hw_crc32 to tf_crc32
feat(fwu): avoid booting with an

Merge changes from topic "fw-update-2" into integration

* changes:
feat(sw_crc32): add software CRC32 support
refactor(hw_crc32): renamed hw_crc32 to tf_crc32
feat(fwu): avoid booting with an alternate boot source
docs(fwu): add firmware update documentation
feat(fwu): avoid NV counter upgrade in trial run state
feat(plat/arm): add FWU support in Arm platforms
feat(fwu): initialize FWU driver in BL2
feat(fwu): add FWU driver
feat(fwu): introduce FWU platform-specific functions declarations
docs(fwu_metadata): add FWU metadata build options
feat(fwu_metadata): add FWU metadata header and build options

show more ...

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
address

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>

show more ...

Merge changes from topic "fw_config_handoff" into integration

* changes:
doc: Update memory layout for firmware configuration area
plat/arm: Increase size of firmware configuration area
plat/a

Merge changes from topic "fw_config_handoff" into integration

* changes:
doc: Update memory layout for firmware configuration area
plat/arm: Increase size of firmware configuration area
plat/arm: Load and populate fw_config and tb_fw_config
fconf: Handle error from fconf_load_config
plat/arm: Update the fw_config load call and populate it's information
fconf: Allow fconf to load additional firmware configuration
fconf: Clean confused naming between TB_FW and FW_CONFIG
tbbr/dualroot: Add fw_config image in chain of trust
cert_tool: Update cert_tool for fw_config image support
fiptool: Add fw_config in FIP
plat/arm: Rentroduce tb_fw_config device tree

show more ...

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_conf

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

show more ...

Merge changes from topic "sp_secure_boot" into integration

* changes:
dualroot: add chain of trust for secure partitions
sptool: append cert_tool arguments.
cert_create: add SiP owned secure p

Merge changes from topic "sp_secure_boot" into integration

* changes:
dualroot: add chain of trust for secure partitions
sptool: append cert_tool arguments.
cert_create: add SiP owned secure partitions support

show more ...

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
b

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

show more ...

Merge changes from topic "tbbr/fw_enc" into integration

* changes:
docs: qemu: Add instructions to boot using FIP image
docs: Update docs with firmware encryption feature
qemu: Support optiona

Merge changes from topic "tbbr/fw_enc" into integration

* changes:
docs: qemu: Add instructions to boot using FIP image
docs: Update docs with firmware encryption feature
qemu: Support optional encryption of BL31 and BL32 images
qemu: Update flash address map to keep FIP in secure FLASH0
Makefile: Add support to optionally encrypt BL31 and BL32
tools: Add firmware authenticated encryption tool
TBB: Add an IO abstraction layer to load encrypted firmwares
drivers: crypto: Add authenticated decryption framework

show more ...

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

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

show more ...

Merge changes from topic "sp_loading" into integration

* changes:
SPMD: loading Secure Partition payloads
fvp: add Cactus/Ivy Secure Partition information
fconf: Add Secure Partitions informat

Merge changes from topic "sp_loading" into integration

* changes:
SPMD: loading Secure Partition payloads
fvp: add Cactus/Ivy Secure Partition information
fconf: Add Secure Partitions information as property

show more ...

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 im

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>

show more ...

Merge changes I0d17ba6c,I540741d2,I9e6475ad,Ifd769320,I12c04a85, ... into integration

* changes:
plat/mediatek/mt81*: Use new bl31_params_parse() helper
plat/rockchip: Use new bl31_params_parse_

Merge changes I0d17ba6c,I540741d2,I9e6475ad,Ifd769320,I12c04a85, ... into integration

* changes:
plat/mediatek/mt81*: Use new bl31_params_parse() helper
plat/rockchip: Use new bl31_params_parse_helper()
Add helper to parse BL31 parameters (both versions)
Factor out cross-BL API into export headers suitable for 3rd party code
Use explicit-width data types in AAPCS parameter structs
plat/rockchip: Switch to use new common BL aux parameter library
Introduce lightweight BL platform parameter library

show more ...

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-

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>

show more ...