Change Log & Release Notes

This document contains a summary of the new features, changes, fixes and known issues in each release of Trusted Firmware-M.

Version 1.2.0

New features

  • A new build system based on Modern CMake.

  • First implementation of level 3 isolation on Musca-B1 and AN521.

  • Remove MCUBoot fork from TF-M.

  • Move test and app code to tf-m-tests repo.

  • Add Profile Medium.

  • Migrate support to Mbed TLS v2.24.

  • New platforms added. See New platforms supported for details.

  • New SPM HAL APIs including isolation API and logging API.

  • Update MCUboot version to 1.7.0-rc1.

  • Initial ITS/PS HAL for dynamic filesystem configuration.

  • Remove auto-generated files from the source tree.

New security advisories

Stack sealing

Refer to Advisory TFMV-1 for more details. A common mitigation is included in this release.

Tested platforms

The following platforms are successfully tested in this release.

  • AN519

  • AN521

  • Musca-B1

  • MPS2 SSE300

  • PSoC 64

  • M2351

  • nrf5340dk

  • nrf5340pdk

  • nrf9160dk

  • LPCXpresso55S69

  • NUCLEO-L552ZE-Q

  • STM32L562E-DK

Known issues

Some open issues exist and will not be fixed in this release.

Descriptions

Issue links

PSA Arch Crypto tests have several known failures.

See this link for detailed analysis of the failures: https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_failure_analysis_in_tf-m_v1.2_release/

Issues fixed since 1.1

Issues fixed by TF-M since v1.1 are listed below.

Descriptions

Issue links

The eflash driver on Musca-B1 can return random failures hence
triggering random failures during PSA Arch ITS and PSA Arch PS tests.
This happens when ITS/SST is configured to use flash.

https://developer.trustedfirmware.org/T697

Issues closed since 1.1

The following issues are closed since v1.1. These issues are related to platform hardware limitations or 3rd-party tools and therefore won’t be fixed by TF-M.

Descriptions

Issue links

All the supported GNUARM toolchain versions generate corrupt veneer
code for Armv8-M baseline architecture, when the -Os optimization flag
is used. This affects the Armv8-M baseline platforms built with GNUARM
toolchain and Minsizerel build type.
It relies on an official release of GNUARM toolchain to fix this issue.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646

AN521 FVP soft reset via AIRCR does not reset MPC / PPC / MPU and will
cause boot failure. This is a known issue for AN521 FVP. This will
cause the system to fail to boot after a warm reset during PSA Arch FF
testing.

https://developer.trustedfirmware.org/T692

There are 2 additional failures for PSA-Arch Crypto tests with CC-312
other than the known failures. This is due to limitation of CC-312
implementation as it does not support MD_NONE hashing mode causing the
additional failures.

https://developer.trustedfirmware.org/T691

Boot up fails if there is unexpected data in flash on Musca-A. The boot
is successful and the tests pass if all the associated (PS/ITS/NV
Counter) flash areas are erased.

https://developer.trustedfirmware.org/T694

If the flash is not erased, boot fails on Musca-B1 when SST is using
flash for Minsizerel config.

https://developer.trustedfirmware.org/T695


Copyright (c) 2020, Arm Limited. All rights reserved.

Version 1.1

New Features

  • Upgraded MCUBoot to v1.6.0., default is now the upstream MCUBoot instead of the TF-M fork.

  • TF-Fuzz tool for fuzz testing PSA APIs.

  • Updated Source code folder structure.

  • IAR compiler support.

  • LPCXpresso55S69-EVK board support.

  • Add Profile Small.

  • Enable Ninja CMake Generator.

  • FVP_SSE300_MPS2 platform support.

  • Rename SST(Secure STorage) to PS(Protected Storage) and partition moved from PSA Root of Trust to Application Root of Trust.

  • NUCLEO-L552ZE-Q and DISCO-L562QE platform support.

  • Restructure documentation to make it more user-friendly.

  • Enable Attestation service to use symmetric key algorithm.

  • Use CMSIS for testing from tf-m-tests repository. This removes dependency on the external CMSIS_5 repo.

New Platforms supported

New Platforms limitations

  • LPCXpresso55S69-EVK doesn’t support BL2.

  • LPCXpresso55S69-EVK doesn’t support ARMCLANG and IARARM toolchain. Patch with support for IARARM is available at review.trustedfirmware.org #4023

  • FVP_SSE300_MPS2 doesn’t support GNUARM and IARARM toolchain. Patch with support for IARARM is available at review.trustedfirmware.org #4574

Known issues

Some open issues exist and will not be fixed in this release.

All the supported GNUARM toolchain versions generate corrupt veneer
code for Armv8-M baseline architecture, when the -Os optimization flag
is used. This affects the AN519 and AN539 platforms built with GNUARM
toolchain and Minsizerel build type.

Issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646

PSA Arch Crypto tests have several known failures.

See this link for detailed analysis of the failures : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/test_failure_analysis.md

AN521 FVP soft reset via AIRCR does not reset MPC / PPC / MPU and will
cause boot failure. This is known issue for AN521 FVP. This will cause
the system to not boot after a warm reset during PSA Arch FF testing.

Issue: https://developer.trustedfirmware.org/T692

There are 2 additional failures for PSA-Arch Crypto tests with CC-312
other than the known failures. This is due to limitation of CC-312
implementation as it does not support MD_NONE hashing mode causing the
additional failures.

Issue: https://developer.trustedfirmware.org/T691

Boot up fails if there is unexpected data in flash on Musca-A. The boot
is successful and the tests pass if all the associated (PS/ITS/NV
Counter) flash areas are erased.

Issue: https://developer.trustedfirmware.org/T694

When PS/ITS are using Flash on Musca-B1, PSA Arch FF test fails due to
known warm reset limitation in the platform. There is an issue with
Musca-B1 QSPI flash that causes this failure. The fix is under
investigation.

Issue: https://developer.trustedfirmware.org/T696

Issues fixed since 1.0

The eflash driver on Musca-B1 can return random failures hence
triggering random failures during PSA Arch ITS and PSA Arch PS tests.
This happens when ITS/SST is configured to use flash.

Issue: https://developer.trustedfirmware.org/T697

Release build of PSA Arch Crypto tests have a different number of tests
when built for AN521 FVP. This is an issue in the PSA Arch Crypto
tests.

Issue for PSA Arch Tests project : https://github.com/ARM-software/psa-arch-tests/issues/169


Copyright (c) 2020, Arm Limited. All rights reserved.

Version 1.0

New Features

  • First major release.

  • A Secure FW with support for PSA Level 1 and 2 isolation on Armv8-M using TrustZone extension and Dual-core Cortex-M config.

  • The PSA Firmware Framework (PSA FF)/Dev API interfaces exposed by the Secure FW to NS side.

  • A secure FW model with NS application example.

  • Secure services running within this SPE

    • Secure Storage Service (PSA Protected Storage API - 1.0.0)

    • Attestation (PSA Attestation API 1.0.0)

    • Crypto Service (PSA API 1.0-beta-3)

    • TF-M Audit Log

    • Platform Service

    • Internal Trusted Storage (PSA API 1.0.0)

  • PSA IPC support

  • Support for Armv8-M mainline and baseline and Dual-core Cortex-M systems.

  • Testcases running baremetal and with RTX to test the functionality.

  • BL2 bootloader for image authentication based on SHA256 and RSA-3072 digital signature.

  • Build system based on CMake, supporting ARMCLANG and GNU Arm.

  • Support for integrated CryptoCell-312 cryptographic hardware accelerator on Musca-B1 platform.

  • Meets requirements for Updatable RoT for PSA Functional API, Level 1 and Level 2 Certifications in the feature list.

Platforms supported

Current release has been tested on:

Other supported platforms:

Platform Limitations

  • The PSA Arch Tests need to be split into several binaries to load onto Musca-A board because of low memory available to the NS world to use.

  • The Regression tests on MPS3 AN524 FPGA takes about 40 minutes to complete. This is because AN524 uses QSPI Flash for runtime memory as the RAM is small. The slow speed of QSPI device causes the tests to run slowly.

  • Warm reset of eFlash is not permitted on Musca-B1 due to HW bug https://community.arm.com/developer/tools-software/oss-platforms/w/docs/426/musca-b1-warm-reset-of-eflash As TF-M is executed in place from eFlash on Musca-B1, there is good chance that a warm reset of the board will have unexpected (even non-deterministic) effects on code execution. Hence the PSA Arch FF tests, which rely of warm reset of Musca-B1 were executed on RAM FS using “-DSST_RAM_FS=ON” config.

Known issues

Some open issues exist and will not be fixed in this release.

AN521 FVP soft reset via AIRCR does not reset MPC / PPC / MPU and will cause boot failure. This is known issue for AN521 FVP. This will cause the system to not boot after a warm reset during PSA Arch FF testing.

Issue : https://developer.trustedfirmware.org/T692

PSA Arch Crypto tests have several known failures.

See this link for detailed analysis of the failures : https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/docs/test_failure_analysis.md

There are 2 additional failures for PSA-Arch Crypto tests with CC-312 other than the known failures. This is due to limitation of CC-312 implementation as it does not support MD_NONE hashing mode causing the additional failures.

The issue details are captured here : https://developer.trustedfirmware.org/T691

PS test case 2002 and 1002 does not fail on Musca-B1 flash when run for second time without erasing flash. The WRITE_ONCE assets created by SST module should not be updatable but after reboot, the update seems to happen and is not expected. This issue will happen on any platform using persistent storage for SST.

Issue created : https://developer.trustedfirmware.org/T693

Boot up fails if there is unexpected data in flash on Musca-A. The boot is successful and the tests pass if all the associated (SST/ITS/NV Counter) flash areas are erased.

Issue created : https://developer.trustedfirmware.org/T694

If the flash is not erased, boot fails on Musca-B1 when SST is using flash for Minsizerel config.

Issue created : https://developer.trustedfirmware.org/T695

When SST/ITS are using Flash on Musca-B1, PSA Arch FF test fails due to known warm reset limitation in the platform. But after the failure, Musca-B1 boot fails to boot. This could be related to general issues of the SST module when Flash data is inconsistent.

Issue created : https://developer.trustedfirmware.org/T696

The eflash driver on Musca-B1 can return random failures hence triggering random failures during PSA Arch ITS and PSA Arch PS tests. This happens when ITS/SST is configured to use flash.

Issue created : https://developer.trustedfirmware.org/T697

Release build of PSA Arch Crypto tests have a different number of tests when built for AN521 FVP. This is an issue in the PSA Arch Crypto tests.

Issue created for PSA Arch Tests project : https://github.com/ARM-software/psa-arch-tests/issues/169


Copyright (c) 2020, Arm Limited. All rights reserved.


Copyright (c) 2020, Arm Limited. All rights reserved.