feat(mbedtls): update mbedTLS driver for DRTM support

Updated mbedTLS driver to include mbedTLS functions necessary for a
DRTM supported build.

Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm

feat(mbedtls): update mbedTLS driver for DRTM support

Updated mbedTLS driver to include mbedTLS functions necessary for a
DRTM supported build.

Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Change-Id: If0120374a971519cf84f93e0c59e1a320a72cd97

show more ...

feat(crypto): update crypto module for DRTM support

Updated crypto module to include crypto calls necessary for a
DRTM supported build.

Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Ch

feat(crypto): update crypto module for DRTM support

Updated crypto module to include crypto calls necessary for a
DRTM supported build.

Signed-off-by: Manish V Badarkhe <manish.badarkhe@arm.com>
Change-Id: I4f945997824393f46864b7fb7fd380308a025452

show more ...

refactor(libc): clean up dependencies in libc

- Removing platform dependencies from libc modules.
- Replacing panicking with actual error handling.
- Debug macros are included indirectly from assert

refactor(libc): clean up dependencies in libc

- Removing platform dependencies from libc modules.
- Replacing panicking with actual error handling.
- Debug macros are included indirectly from assert.h. Removing
"platform_def.h" from assert.h and adding "common/debug.h"
where the macros are used.
- Removing hack for fixing PLAT_LOG_LEVEL_ASSERT to 40.
Instead removing assert with expression, as this
does not provide additional information.

Signed-off-by: Claus Pedersen <claustbp@google.com>
Change-Id: Icc201ea7b63c1277e423c1cfd13fd6816c2bc568

show more ...

Merge changes from topic "mb_hash" into integration

* changes:
refactor(imx): update config of mbedtls support
refactor(qemu): update configuring mbedtls support
refactor(measured-boot): mb al

Merge changes from topic "mb_hash" into integration

* changes:
refactor(imx): update config of mbedtls support
refactor(qemu): update configuring mbedtls support
refactor(measured-boot): mb algorithm selection

show more ...

refactor(measured-boot): mb algorithm selection

With RSS now introduced, we have 2 Measured Boot backends. Both backends
can be used in the same firmware build with potentially different hash
algori

refactor(measured-boot): mb algorithm selection

With RSS now introduced, we have 2 Measured Boot backends. Both backends
can be used in the same firmware build with potentially different hash
algorithms, so now there can be more than one hash algorithm in a build.
Therefore the logic for selecting the measured boot hash algorithm needs
to be updated and the coordination of algorithm selection added. This is
done by:

- Adding MBOOT_EL_HASH_ALG for Event Log to define the hash algorithm
to replace TPM_HASH_ALG, removing reference to TPM.

- Adding MBOOT_RSS_HASH_ALG for RSS to define the hash algorithm to
replace TPM_HASH_ALG.

- Coordinating MBOOT_EL_HASH_ALG and MBOOT_RSS_HASH_ALG to define the
Measured Boot configuration macros through defining
TF_MBEDTLS_MBOOT_USE_SHA512 to pull in SHA-512 support if either
backend requires a stronger algorithm than SHA-256.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I4ddf06ebdc3835beb4d1b6c7bab5a257ffc5c71a

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

build(deps): upgrade to mbed TLS 2.28.0

Upgrade to the latest and greatest 2.x release of Mbed TLS library
(i.e. v2.28.0) to take advantage of their bug fixes.

Note that the Mbed TLS project publis

build(deps): upgrade to mbed TLS 2.28.0

Upgrade to the latest and greatest 2.x release of Mbed TLS library
(i.e. v2.28.0) to take advantage of their bug fixes.

Note that the Mbed TLS project published version 3.x some time
ago. However, as this is a major release with API breakages, upgrading
to 3.x might require some more involved changes in TF-A, which we are
not ready to do. We shall upgrade to mbed TLS 3.x after the v2.7
release of TF-A.

Actually, the upgrade this time simply boils down to including the new
source code module 'constant_time.c' into the firmware.

To quote mbed TLS v2.28.0 release notes [1]:

The mbedcrypto library includes a new source code module
constant_time.c, containing various functions meant to resist timing
side channel attacks. This module does not have a separate
configuration option, and functions from this module will be
included in the build as required.

As a matter of fact, if one is attempting to link TF-A against mbed
TLS v2.28.0 without the present patch, one gets some linker errors
due to missing symbols from this new module.

Apart from this, none of the items listed in mbed TLS release
notes [1] directly affect TF-A. Special note on the following one:

Fix a bug in mbedtls_gcm_starts() when the bit length of the iv
exceeds 2^32.

In TF-A, we do use mbedtls_gcm_starts() when the firmware decryption
feature is enabled with AES-GCM as the authenticated decryption
algorithm (DECRYPTION_SUPPORT=aes_gcm). However, the iv_len variable
which gets passed to mbedtls_gcm_starts() is an unsigned int, i.e. a
32-bit value which by definition is always less than 2**32. Therefore,
we are immune to this bug.

With this upgrade, the size of BL1 and BL2 binaries does not appear to
change on a standard sample test build (with trusted boot and measured
boot enabled).

[1] https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.0

Change-Id: Icd5dbf527395e9e22c8fd6b77427188bd7237fd6
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

show more ...

refactor(mbedtls): allow platform to specify their config file

Common mbedTLS implementation include the fixed configuration
file of mbedTLS and that does not gives flexilibility to the
platform to

refactor(mbedtls): allow platform to specify their config file

Common mbedTLS implementation include the fixed configuration
file of mbedTLS and that does not gives flexilibility to the
platform to include their own mbedTLS configuration.
Hence changes are done so that platform can include their own
mbedTLS 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

show more ...

refactor(measured-boot): avoid Measured-Boot dependency on Trusted-Boot

Measured-Boot and Trusted-Boot are orthogonal to each other and hence
removed dependency of Trusted-Boot on Measured-Boot by m

refactor(measured-boot): avoid Measured-Boot dependency on Trusted-Boot

Measured-Boot and Trusted-Boot are orthogonal to each other and hence
removed dependency of Trusted-Boot on Measured-Boot by making below
changes -
1. BL1 and BL2 main functions are used for initializing Crypto module
instead of the authentication module
2. Updated Crypto module registration macro for MEASURED_BOOT with only
necessary callbacks for calculating image hashes
3. The 'load_auth_image' function is now used for the image measurement
during Trusted or Non-Trusted Boot flow

Change-Id: I3570e80bae8ce8f5b58d84bd955aa43e925d9fff
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

refactor(measured-boot): add generic macros for using Crypto library

It doesn't look correct to use mbed TLS defines directly in the Event
Log driver as this driver may use another Crypto library in

refactor(measured-boot): add generic macros for using Crypto library

It doesn't look correct to use mbed TLS defines directly in the Event
Log driver as this driver may use another Crypto library in future.
Hence mbed TLS Crypto dependency on Event Log driver is removed by
introducing generic Crypto defines and uses those in the Event Log
driver to call Crypto functions.
Also, updated mbed TLS glue layer to map these generic Crypto defines
to mbed TLS library defines.

Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ibc9c751f60cbce4d3f3cf049b7c53b3d05cc6735

show more ...

fix(cc-713): fix a build failure with CC-713 library

Fixed a below build failure with CC-713 library
error:
implicit declaration of function ‘mbedtls_x509_get_rsassa_pss_params’
[-Werror=implicit-fu

fix(cc-713): fix a build failure with CC-713 library

Fixed a below build failure with CC-713 library
error:
implicit declaration of function ‘mbedtls_x509_get_rsassa_pss_params’
[-Werror=implicit-function-declaration]

Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: If298ec16d133cf54413c299327b2c007ec4117b2

show more ...

fvp_r: load, auth, and transfer from BL1 to BL33

Adding load, authentication, and transfer functionality from FVP R BL1 to
BL33, which will be the partner runtime code.

Signed-off-by: Lauren Wehrme

fvp_r: load, auth, and transfer from BL1 to BL33

Adding load, authentication, and transfer functionality from FVP R BL1 to
BL33, which will be the partner runtime code.

Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I293cad09739dacac0d20dd57c1d98178dbe84d40

show more ...

feat(fwu): avoid NV counter upgrade in trial run state

Avoided NV counter update when the system is running in
trial run state.

Change-Id: I5da6a6760f8a9faff777f2ff879156e9c3c76726
Signed-off-by: M

feat(fwu): avoid NV counter upgrade in trial run state

Avoided NV counter update when the system is running in
trial run state.

Change-Id: I5da6a6760f8a9faff777f2ff879156e9c3c76726
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

fix(driver/auth): avoid NV counter upgrade without certificate validation

Platform NV counter get updated (if cert NV counter > plat NV counter)
before authenticating the certificate if the platform

fix(driver/auth): avoid NV counter upgrade without certificate validation

Platform NV counter get updated (if cert NV counter > plat NV counter)
before authenticating the certificate if the platform specifies NV
counter method before signature authentication in its CoT, and this
provides an opportunity for a tempered certificate to upgrade the
platform NV counter. This is theoretical issue, as in practice none
of the standard CoT (TBBR, dualroot) or upstream platforms ones (NXP)
exercised this issue.

To fix this issue, modified the auth_nvctr method to do only NV
counter check, and flags if the NV counter upgrade is needed or not.
Then ensured that the platform NV counter gets upgraded with the NV
counter value from the certificate only after that certificate gets
authenticated.

This change is verified manually by modifying the CoT that specifies
certificate with:
1. NV counter authentication before signature authentication
method
2. NV counter authentication method only

Change-Id: I1ad17f1a911fb1035a1a60976cc26b2965b05166
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...