Hi all,
We've created a change, which is using original CMSIS headers in TF-M. Current patch is only for arm/mps3/an552 platform. Our plan is to create a public review only for this (which will NOT be merged), and after the review, we would like to extend this patch to all of the platforms.
The main changes in the chain:
- copy and zero_table size fix in the GNU linker scripts and initial startup code
- Removed __INITIAL_SP and __STACK_LIMIT patch form gcc and iar cmsis files, NS linker scripts using CMSIS style naming, the secure and bl2 build's linker scripts remains untouched (ARMCLANG style naming, __INITIAL_SP and __STACK_LIMIT patched with cmsis_stack_override interface library)
- NS process stack removed from NS linkers (PSP)
- Common startup file for bl2 and ns builds
- Add original cmsis headers, updated system and startup files
- Stack sealing done twice, once from startup (to resemble CMSIS startup template) and once from TF-M secure main
Feedback is welcome:
https://review.trustedfirmware.org/q/topic:%2522use-original-cmsis-headers%…
David Hazi
Hi everyone,
I have several questions related to L3 isolation in TFM.
First of all, FFM specifies that:
* In L3 PSA RoT partitions does not need to be isolated from SPM (and vice versa)
* PSA RoT partitions does not need to be isolated from each other
* PSA RoT partitions and SPM must be isolated from APP RoT partitions
* APP RoT partitions must be isolated from each other
This picture from TFM docs<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> seem to illustrate statements above.
Currently platforms with L3 support (e.g. an521) follow the rules stated above.
They achieve this by executing PSA RoT partitions and SPM in privileged mode, and APP RoT partitions in unprivileged mode. Partition boundaries are only updated when switching to APP RoT partition.
From description of tfm_hal_activate_boundary (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) and this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> seems like platform can determine whether partition will be executed in privileged or unprivileged mode.
So my questions are:
1. For improved isolation in L3 does it make sense to:
* isolate SPM from PSA RoT partitions
* isolate PSA RoT partitions from each other (like APP RoT partitions are isolated)
1. If question 1 make sense then can platform achieve this improved isolation with current code base?
From this an521 code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> it seems like platform may set all partitions to be executed in unprivileged mode and dynamically switch boundaries between them (between both PSA and APP RoT partitions). SPM will remain in privileged mode.
It seems like this approach is possible with minor changes to SPM. For example this code will need<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…> to be changed to call tfm_hal_activate_boundary regardless of partition privilege level.
Are there any other changes needed to make this approach work?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi everyone,
I have several questions related to partition assets attributes.
FFM specifies 2 types of assets (mmio_regions):
* Named MMIO region
* Numbered MMIO region
FFM does not really specify the use cases for these 2 different types.
I expect that Named region is only used for peripherals and numbered region is only used for memory regions.
Am I right here? If no, then what the use cases for these 2 types are and what is currently supported in TFM?
Also I see that in tools/templates/partition_load_info.template lines 221-224 ASSET_ATTR_NUMBERED_MMIO or ASSET_ATTR_NAMED_MMIO are assigned for assets from manifest files depending on their type, but tools/templates/partition_load_info.template#187<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/tools/temp…> does not assign any of these attributes for "PART_REGION_ADDR(PT_{{manifest.name}}_PRIVATE, _DATA_START$$Base)" at isolation level 3.
Is this some a bug or I am missing some knowledge on this mmio_regions stuff?
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hello,
Following tech forum today and the presentation on August 18 (to be published asap), I propose to deprecate TF-M library model as an obsolete and replace it with SFN model as a successor.
PSA compliant SFN and IPC, defined in FF_M will then be the 2 supported models in TF-M going forward.
Please share your thoughts and concerns on the proposal.
Having no objections, we will depreciate the Library model after October 1 and it will be removed in TF-M v1.7.0
Thanks, and best regards,
Anton
Hi,
we wish to avoid the pitfalls of "doing your own security", and at the same time not use
dummy/template code that is not meant for production.
May I ask if it is still accurate what the docs say here about the template folder, namely that
nothing in the template folder should be used in production without being ported first?
This directory contains platform-independent dummy implementations of the interfaces in platform/include. These implementations can be built directly for initial testing of a platform port, or used as a basic template for a real implementation for a particular target. They must not be used in production systems.
$ ls platform/ext/common/template/
attest_hal.c flash_otp_nv_counters_backend.c otp_flash.c tfm_initial_attest_pub_key.c
crypto_keys.c flash_otp_nv_counters_backend.h tfm_fih_rng.c tfm_rotpk.c
crypto_nv_seed.c nv_counters.c tfm_initial_attestation_key.pem tfm_symmetric_iak.key
Hi.
I was testing the SFN model on the TF-M 1.6 release and I am confused about which API source files should be used for the non-secure application.
The documentation here is lacking, so I am going by what we do in the build scripts of TF-M and tf-m-tests.
The non-secure source files that are exported and included in the nonsecure API library are tfm_<partition>_ipc_api.c.
This strikes me as odd, to use the IPC source files for the SFN model. If this is correct the naming is misleading.
From the code the selection is done based on PSA_API definition.
Based on this if this is the correct source files to use then I would think this should either be documented or renamed to something that better reflect the use, perhaps tfm_<partition>_psa_api.c?
In the documentation there is a lot of room for improvements, the existence of tfm_<partition>_secure_api.c could lead to confusion since it is not always well described.
tfm_attestation_integration_guide.rst:
System integrators might need to port these interfaces to a custom secure
partition manager implementation (SPM). Implementations in TF-M project can be
found here:
- ``interface/src/tfm_initial_attestation_func_api.c``: non-secure interface
implementation for library model
- ``interface/src/tfm_initial_attestation_ipc_api.c``: non-secure interface
implementation for IPC model
- ``secure_fw/partitions/initial_attestation/tfm_attestation_secure_api.c``:
secure interface implementation
Here it is not clear to me what "secure interface implementation" means, it could be interpreted as the SFN API.
tfm_crypto_integration_guide.rst:
- ``tfm_crypto_secure_api.c`` : This module implements the PSA Crypto API
client interface exposed to the Secure Processing Environment
Here it is clearer that tfm_<partition>_secure_api.c is the interface to the SPE.
However the documented NSPE interface source file does not even exist, and does not explain the IPC / FUNC difference:
| NSPE client API interface | This module exports the client API of PSA Crypto to the NSPE | ``./interface/src/tfm_crypto_api.c``
tfm_fwu_service.rst:
| NSPE client API interface | This module exports the client API of PSA Firmware Update to | ``./interface/src/tfm_firmware_update_func_api.c`` |
| | the NSPE(i.e. to the applications). | ``./interface/src/tfm_firmware_update_ipc_api.c`` |
Here it is mentioned the two possible source files, but it is not specified when to use which source file.
Generally:
Between all the services this is not consistently listed, for example the tfm_its_service.rst file does not have the table of source files.
If there is a general description of the non-secure interface sources, I couldn't find it.
-Joakim AnderSSON
Hi,
I am not too familiar with TF-M, so please forgive me if this is a silly
question.
The protected storage APIs appear to require the use of on-die flash to
store a non-volatile counter that is used for rollback protection. This is
severely limiting in terms of the number of writes, because basically you
get as many writes as the endurance of the flash on the MCU (for example,
the nordic cortex M33 devices have a rated write endurance of 10k cycles
per page, and I don't think there is any wear levelling in TF-M). For
example, assuming that a device was configured to write to the protected
storage on boot, one could pretty easily exhaust this flash in a few hours
by continuously power cycling it. Even if the 10k writes is a very
conservative rating, it seems pretty likely that the counter flash will
fail before UINT32_MAX.
My question is: what happens to the security and functionality of the
protected storage if the internal NV flash write fails silently? I don't
know much about the semiconductor physics at play here, but presumably it
could fail to make the counter a constant number, or fail to a random
number.
I had a quick look but there don't appear to be any checks in the code to
ensure that a value was actually written correctly to the NV counters flash
in case of silent corruption - it seems to just assume that any error would
be detectable by some return code from the flash write driver. I was
looking for some check like:
if (value_to_write != value_read_back) return FLASH_WORN_OUT_ERROR;
But I wasn't able to find it. So assuming it isn't actually there, if the
counter fails to a constant (which is not UINT32_MAX) then presumably the
rollback protection would be broken for all writes after that point (and
maybe some before depending on the constant). If it fails to a random
number, then it would be broken in a more "random" way - ie it would
randomly work/not work depending on the value of the counter, until all
UINT32_MAX numbers are randomly selected as the counter value.
Also, given that typical AEAD ciphers like AES-GCM typically fail
catastrophically with nonce reuse and the protected storage is indeed AEAD
(though I can't quite work out yet which cipher is used), if these
non-volatile counters are used to generate a nonce then potentially the
encryption of the device could be broken just by rebooting the device until
the flash is worn out, and then the nonce will be reused if the flash fails
to a constant value.
Could someone please help me clear up if my understanding here is correct?
As is, I am struggling a bit to understand how to use the protected storage
API in a secure way with this constraint, because if an attacker has any
way to repeatedly cause a flash write it is basically game over. Any help
would be greatly appreciated.
Thanks,
Jeremy
