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
Hi George,
The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also
“”””””””””””””””””””
1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device.
2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT).
“”””””””””””””””””””
So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead?
For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable.
As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time.
Regards,
Sherry Zhang
From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Sent: Friday, September 24, 2021 8:52 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello Sherry,
Thank you for your input!
1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model.
2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option.
3. Agreed, a HAL API should be used for this.
Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS.
Regards,
George
________________________________
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Friday, September 24, 2021 11:58 AM
To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] Supporting encryption with ITS
Hi George,
Some comments from my side:
1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS?
2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes.
3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption.
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Thursday, September 23, 2021 10:47 PM
To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Supporting encryption with ITS
Hey Gyorgy,
These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls.
Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think.
________________________________
From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>
Sent: Thursday, September 23, 2021 4:30 PM
To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] Supporting encryption with ITS
Hi,
AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS.
You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines.
Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 )
/George
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M
Sent: September 23, 2021 15:51
To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Supporting encryption with ITS
Hi George,
I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.*
Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture.
Greetings,
Fabian Schmidt
* at least short of a sophisticated physical attack or finding some loophole in TrustZone…
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Donnerstag, 23. September 2021 15:28
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [EXT] [TF-M] Supporting encryption with ITS
Caution: EXT Email
Hey all,
Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers.
At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later.
What are your thoughts on this?
Regards,
George
Hi Chris,
RSS build requires new runtime Measured Boot Service. This service partition is not yet part of PSA specification and hence it resides in the tf-m-extras repository. (https://git.trustedfirmware.org/TF-M/tf-m-extras.git/)
For out of tree partition build, if you map the tf-m-extras repo and provideTFM_EXTRA_MANIFEST_LIST_FILES =<path_to_measured_boot_manifest_list.yaml> and TFM_EXTRA_PARTITION_PATHS=<path_to_measured_boot_partition> (example as below), then it should fix build issue.
-DTFM_EXTRA_MANIFEST_LIST_FILES=../../tf-m-extras/partitions/measured_boot/measured_boot_manifest_list.yaml
-DTFM_EXTRA_PARTITION_PATHS=../../tf-m-extras/partitions/measured_boot
If the error persists, could you please send me the build options you are using and I'll look into this further.
Best Regards,
Maulik
________________________________
From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org>
Sent: Wednesday, September 7, 2022 1:00 AM
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: TF-M Digest, Vol 47, Issue 7
Send TF-M mailing list submissions to
tf-m(a)lists.trustedfirmware.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
tf-m-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
tf-m-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of TF-M digest..."
Today's Topics:
1. Status of RSS platform? (Chris.Brand(a)infineon.com)
----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Sep 2022 21:48:05 +0000
From: <Chris.Brand(a)infineon.com>
Subject: [TF-M] Status of RSS platform?
To: <tf-m(a)lists.trustedfirmware.org>
Message-ID: <2441d128df93483abc1da39c38e89885(a)infineon.com>
Content-Type: multipart/alternative;
boundary="_000_2441d128df93483abc1da39c38e89885infineoncom_"
Hi,
I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code).
I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions.
Thanks,
Chris Brand
Cypress Semiconductor (Canada), Inc.
An Infineon Technologies Company
Sr Prin Software Engr
CSCA CSS ICW SW PSW 1
Office: +1 778 234 0515
Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>
International Place 13700
V6V 2X8 Richmond
Canada
www.infineon.com<www.cypress.com<http://www.cypress.com>> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies>
Part of your life. Part of tomorrow.
NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.
Hello,
Recently we discussed the movement of relevant options into C header files as a potential configuration improvement.
By this mail thread, I would like to provoke discussion on what else we are lacking in TF-M configurability and thoughts to make it better.
Please share your ideas to review them in the upcoming tech forum.
Thanks,
Anton
Hi,
I'm wondering what the status of the RSS platform is. I tried to build it from the current HEAD of master and also from a few earlier commits, and cannot get it to build (I get an error about TFM_MEASURED_BOOT_SID being undeclared in some of the generated code).
I was curious about the implementation of tfm_hal_get_mem_security_attr(), tfm_hal_get_secure_access_attr() and tfm_hal_get_ns_access_attr() on an ARMv8 multi-core platform, but there doesn't currently seem to be an implementation of those HAL functions.
Thanks,
Chris Brand
Cypress Semiconductor (Canada), Inc.
An Infineon Technologies Company
Sr Prin Software Engr
CSCA CSS ICW SW PSW 1
Office: +1 778 234 0515
Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>
International Place 13700
V6V 2X8 Richmond
Canada
www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies>
Part of your life. Part of tomorrow.
NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.
Hello,
when building TF-M you get the same result no matter what
computer you build from assuming all the tooling is the same version.
The builds are reproducible in other words.
But when building TF-M together with the tests, e.g. by building the regression test suite
you will get a different binary depending on where in the filesystem the tf-m-tests repository
has been installed.
This is because the TEST_FAIL macro uses the gcc macro _FILE_ which injects the absolute paths of source files
into strings in the binary.
This is a big problem for people using CI systems as a different sized binary can affect race conditions,
flash region usage overflows, etc..
I think we should make builds reproducible by default, possibly with a configuration for adding absolute paths
into the binary for those that prefer so.
I would like to write a patch to this affect, but would prefer to get some feedback now so I don't have to re-write it in review.
The simplest solution is to remove __FILE__ from the TEST_FAIL macro,but this would remove useful information and may also fail in the future if someone else uses __FILE__.
The more common way of solving this problem is to add a flag to the compiler that instructs it to replace any occurrences of the absolute path with something else during macro expansion. For instance replace "C:/repos/tf-m-tests/source_file.c" with "TFM_TESTS/source_file.c". For gcc the flag is -fmacro-prefix-map=<old_string>=<new_string>. I don't know what the flag is for the other supported compilers or if they support it at all.
Would it be OK to only support reproducible builds for the compilers that support an equivalent of macro-prefix-map?
