Add TF-M to Mbed OS, replacing the previous PSA implementation for
TF-M-capable targets. This commit adds files imported from TF-M, without
modification. The version of TF-M imported can be found in
`features/FEATURE_PSA/TARGET_TFM/VERSION.txt`.
These changes switch to TF-M as the sole PSA implementation for v8-M and
dual core targets, with TF-M running on the secure side and Mbed OS
running on the non-secure side. Single core v7-M targets will continue
to have PSA implemented via PSA emulation, implemented by Mbed OS.
Move or remove many PSA-implementing files, as PSA will be provided by
TF-M on non-single-v7-M targets. Delete any files that are not relevant
for PSA emulation mode.
- Remove imported TF-M SPM
- Remove Mbed SPM and tests
- Remove Mbed-implemented PSA services and tests
- Remove PSA_SRV_IMPL, PSA_SRV_IPC, PSA_SRV_EMUL and NSPE.
- Replace PSA_SRV_EMUL and PSA_SRV_IMPL with MBED_PSA_SRV
- Remove any files autogenerated by
"tools/psa/generate_partition_code.py", which no longer exists.
Add new feature `PSA` to support PSA in Mbed OS.
Move the Mbed OS implementation of PSA services for v7-M targets (which
employ PSA emulation, and don't yet use TF-M) to
features/FEATURE_PSA/TARGET_MBED_PSA_SRV. Update the `requires`
attribute in TESTS/configs/baremetal.json to avoid breaking baremetal
testing builds.
Update .astyleignore to match new directory structure
Update Mbed TLS importer to place files into FEATURE_PSA
Create the following generic PSA targets:
* `PSA_Target` (Root level PSA generic target)
* `PSA_V7_M` (Single v7-M PSA generic target)
* `PSA_DUAL_CORE` (Dual-core PSA generic target)
* `PSA_V8_M` (v8-M PSA generic target)
Flatten MUSCA_NS and private MUSCA targets into public MUSCA targets.
Move mcuboot.bin to flat location (removing prebuilt folder)
Signed-off-by: Devaraj Ranganna <devaraj.ranganna@arm.com>
Signed-off-by: Jaeden Amero <jaeden.amero@arm.com>
When using Mbed Crypto's PSA Entropy Injection feature on Mbed OS, it is
not required to opt out of having entropy sources added to your entropy
contexts by default (via MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES).
As integrated in Mbed OS, MBEDTLS_PSA_INJECT_ENTROPY is compatible with
actual entropy sources. PSA entropy injection is implemented using the
standard Mbed TLS NV Seed feature, and is as compatible with other
entropy sources as the standard Mbed TLS NV Seed feature which does
support entropy mixing.
Automatically enable entropy injection when the NV Seed feature is
requested on PSA targets. Add a warning note describing the state of the
current implementation of the entropy injection API.
Fixes#10720
This commit makes the storage configurations - setting
MBEDTLS_PSA_CRYPTO_STORAGE_C, MBEDTLS_PSA_CRYPTO_STORAGE_ITS_C and unsetting
MBEDTLS_PSA_CRYPTO_STORAGE_FILE_C - dependent on the PSA label being defined for
the target.
Previously these symbols were always defined for all platforms which could
cause problems for targets that don't yet support PSA.
To avoid collisions between the psa `crypto_platform.h` file and the
platform specific `crypto_platform.h` file, for the init \ terminate
functions, rename the latter to `crypto_device_platform`.
The DEVICE_FOO macros are always defined (either 0 or 1).
This patch replaces any instances of a define check on a DEVICE_FOO
macro with value test instead.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Change error from `MBEDTLS_PLATFORM_HW_FAILED` to
`MBEDTLS_PLATFORM_HW_ACCEL_FAILED` and the value to 0x70,
as the previous value cannot be used as a low level error code.
1. Move the `mbedtls_platform_context` to be platform code, in `features/mbedtls/platfrom/`.
2. Add static refernce counter, to setup and teardown the platform code only once.
3. Adjust Cryptocell porting accordingly.
The configuration option for the mbed TLS specific hardware acceleration
has to be in the macro section and not in the device capabilities
section in targets.json.
The option has also been renamed to better reflect its function.
The crypto hardware acceleration might require defining a lot of mbed
TLS specific macros. Enumerating all of them in `targets.json` creates
too much noise, therefore we move it into a target specific mbed TLS
header.
The target with crypto hardware acceleration has to
- indicate its capability in `targets.json` by adding "CRYPTO"
to the "device_has" section
- has to define his crypto hardware acceleration related macros
in an `mbedtls_device.h` header
- place the `mbedtls_device.h` file in the
`features/mbedtls/targets/TARGET_XXXX`
directory specific to the target
Devaraj Ranganna
Antti Kauppila
Teppo Järvelin
Jaeden Amero
Simon Butcher
Alexander Zilberkant
Ron Eldor
Alastair D'Silva
Janos Follath
Andres AG