Hi all,
The goal of this proposal is to separate TF-M core and platform code to simplify development and support.
Take, for example, the Cypress PSoC 64 platform, we see that a significant amount of code can be committed into the repository.
For end user perspective, it doesn't seem logical that project source tree has a lot of irrelevant stuff. It complicates a performance of IDE, searching and analyzing a code.
Pros :
Platform support can be provided separately without the need to upgrade outdated platforms or problematic platforms :
https://lists.trustedfirmware.org/pipermail/tf-m/2021-January/001454.htmlhttps://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…
It should help to avoid or at least to minimize number of patches that requires fixes in platform folders :
https://lists.trustedfirmware.org/pipermail/tf-m/2019-April/000162.html
Reduces the amount of work for core team by delegating promotion of a new API support to vendors :
https://lists.trustedfirmware.org/pipermail/tf-m/2019-November/000506.html
Proposed solution :
There are other projects that face a similar situation, for example OpenWRT, Yocto, Android. Their common feature is that they have many dependencies. The solution they propose is based on the fact that these projects have their own build infrastructure. The user's task is to create a configuration in which you can add your own components.
In its current state, the TF-M already has some tools to implement platform as an external dependency. The user can specify the path to the platform using the TFM_PLATFORM variable. There is also work underway to implement support of external test infrastructure. (https://lists.trustedfirmware.org/pipermail/tf-m/2021-September/001824.html).
There is a need to add support of external secure partitions instead of current solution (https://tf-m-user-guide.trustedfirmware.org/docs/integration_guide/services…). I can't say if this issue is directly related to the platform, but it's possible that it will give more opportunities to vendors or will be a useful tool for adding new platforms.
The last question that needs to be addressed is how to link the sources supplied by vendors (platforms or security partitions) to the TF-M sources. Using the git submodule mechanism probably is not a good solution. There are two options :
1. Platforms, security partitions and test-suits will be listed as a submodule in the TF-M tree. But this approach will not actually solve the main problem of delegating more responsibility to vendors and breaking the connection between the vendors component and TF-M.
2. The TF-M source tree will be specified as a submodule in modules supplied by vendors. In this case we will have more problems. Because if the user's project will use two or more vendor components (for example, platform and custom security partitions), then TF-M will be mentioned more than once and it is quite possible to have several different revisions of TF-M. So, it will be impossible to properly assemble the project.
Therefore, I see the use of the following approach as an alternative :
1. External components check the TF-M version using the TFM_VERSION variable.
2. A project that uses TF-M, as well as the necessary components (platforms, external security partitions, vendor / project test suites) specifies dependencies using any method. The simplest way is to commit TF-M and vendor components as submodules in the user project.
3. Paths to all dependencies should be transferred from the project to necessary parts of TF-M via CMake variables.
This should be equally convenient for platforms vendors, TF-M components vendors, and TF-M end users.
Risks :
If the project assembled by end user will use several vendor modules (for example platform and custom security partitions). It is possible that the TF-M version required by different vendors modules will be different. But this problem is present at the moment, because any significant change to the TF-M API generates many problems that need to be solved for all supported platforms (mentioned in the pros).
Any feedbacks are welcome.
Best regards,
Roman
Hi everyone,
I'm trying to access an STM32L552 peripheral in a RoT APP (tf-m isolation
v1.4 Level 2), but I'm having trouble doing that.
I know that I have to request the peripheral in the YAML file of my
partition's manifest, but that request didn't work for me. I filled the
required campus and couldn't get access to the peripheral. I'm requesting
the peripheral by putting this piece of code in my partition manifest YAML
file. Am I missing something?
.....
"mmio_regions" : [
{
"name": "TFM_PERIPHERAL_TIMER0",
"permission": "READ-WRITE"
}
......
Another thing, I am only able to request the TIMER0 and UART peripherals?
If I want to access other timers, e.g., TIMER 6 or TIMER 7, am I not
allowed to do so?
Cheers,
Cristiano
Hi, All
Patches for FPU support in TF-M are ready for review now. Looking for your comments!
FPU here refers to Float-point unit for Arm-M profile architecture.
1. FPU support in TF-M
* Support platforms: all platforms with FPU available. Current patches are developed on arm musca_s1 board as example.
* After necessary settings in TF-M, it is configurable that FPU can be enabled in SPE or NSPE, or both sides.
System developer can activate FPU feature on a platform by setting those flags in CMake command line.
i. Enable FP in secure side: -DTFM_SYSTEM_FP= 0-software, 1-hybird, 2-hardware
ii. Enable FP in non-secure side: -DTFM_SYSTEM_FP_NS= 0-software, 1-hybird, 2-hardware
Also lazy stacking feature can be enabled/disabled in SPE or NSPE separately.
iii. Enable lazy stacking in secure side: -DTFM_LAZY_FP=ON
iv. Enable lazy stacking in non-secure side: -DTFM_LAZY_FP_NS=ON
* The secure service developer/application developer does need to know the FPU setting details, they can just compile their program with proper toolchain flags to take advantage of FPU.
The tested toolchains are: GNU Arm embedded toolchain and Arm Compiler. Other toolchain has FPU support should also work but needs test report from partners.
Three floating-point Application Binary Interface (ABI) types of mentioned toolchain are tested: software, hybrid, and hardware option.
* Support isolation level 1,2,3.
* FPU needs to be available in your platform if you want to take the advantage of a hardware FPU.
Please check your platform hardware specification whether FPU is available. Also need to check specification of toolchain whether the FPU architecture of your platform is supported.
FPU architecture can be specified by -DTFM_FP_ARCH in CMake command line.
1. Notes:
* As FF-M alignment is one of our design goals, it only supports IPC partitions at current stage.
* The security mechanism is designed based on ARMv8-M Mainline and later.
* To simplify the scenarios, we defined several guidelines that no involving FPU usage inside an interrupt handler, including deprivileged handler in one Partition.
This can be fine-tuned later if there are requirements that insists a FPU support in handler mode.
* In general, FPU is commonly available on a Armv8.0-M mainline. Please check your platform specification and report exception cases if seen.
1. For the VLLDM instruction security vulnerability of FPU, to mitigate this security vulnerability, it is required to recompile the secure image with compilers that has the software workaround implemented.
For more information, please check https://developer.arm.com/support/arm-security-updates/vlldm-instruction-se….
1. Those patches will be merged in 4-6 weeks if there is no big issue found.
tf-m repo:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11688 FP context protection
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11689 Add FPU support for gnu arm embedded toolchain
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11690 Configure non-secrue timer for FPU test
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11691 Add FPU support design document
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11692 Output support for FP numbers
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11693 FPU support for Armclang compiler
tf-m-tests repo:
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11684 Add FPU support
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11685 Adding FPU test cases
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11686 Adding FPU non-secure interrupt test case
https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11687 Printf support for FP numbers
Best Regards
Feder
Hi everyone,
While reading FWU service doc<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> I found that Components paragraph<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> contain table which says that tfm_bootloader_fwu_abstraction.h file is located in ./secure_fw/partitions/firmware_update/tfm_bootloader_fwu_abstraction.h , but it TF-M repo it is located in secure_fw\partitions\firmware_update\bootloader\tfm_bootloader_fwu_abstraction.h.
Minor thing, but still worth fixing.
Best 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>
I'm working on adding IARARM as a toolchain for the Musca S1 (and B1)
and I'm running into an issue where the NS image can not properly access
the UART.
The NS code loops trying to check the UART status @0x40102030, which
holds the value 0x301, as can be seen with the debugger and also from
the secure code, but when read by the NS code it returns 0, with no error.
As this code works when building with ARMCLANG and GNUARM, I assume
there is some memory protection that gets incorrectly setup when I build
with the IAR toolchain, but I'm struggling to find where this gets
setup. I assume it is done in the secure image.
Any hints where i should be looking?
Thanks,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
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> On Behalf Of Vasilakis,
Georgios via TF-M
Sent: Donnerstag, 23. September 2021 15:28
To: tf-m(a)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
Hello,
Please be informed about the update v1.4.1 containing a hotfix for a vulnerability found in v1.4.0.
The vulnerability exists in Profile Small only so please update to v1.4.1 version if you are currently using TF-M v1.4.0 and Profile Small.
The detailed security advisory will be provided later.
Best regards,
Anton
Thank you both for the input!
Andrej, you are correct that right now PS == Encrypted ITS but my understanding of the spec tells me that this will not always be the case. They do refer to platforms that will use external storage for PS (even though they still require ITS even in this case indeed).
And just to clarify, I don't propose creating yet another ITS. The second thought that I had regarding the refactoring is mainly a common library that both ITS and PS can use for object handling.
Fabian, I also understand it similarly, the ITS is supposed to be trusted on-chip storage which is more protected than PS. And the isolation from TrustZone in normal circumstances should be adequate (at the moment). But physical attacks these days are not that sophisticated anymore, and I think that this is the main driving force for this requirement.
Regards,
George
________________________________
From: Fabian Schmidt
Sent: Thursday, September 23, 2021 3:50 PM
To: Vasilakis, Georgios
Cc: tf-m(a)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> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Donnerstag, 23. September 2021 15:28
To: tf-m(a)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
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 all,
Please be noted that we are changing the build system to build IPC model by default instead of Library model for the following reasons:
* The Library Model is not being developed anymore. It does not support for new FF-M features.
* New comers to TF-M should be encouraged to start with the IPC model to have the better experiences.
* Most importantly, Library Model will be replaced by SFN Model in future.
Patch here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11384
With this patch, the TFM_PSA_API is not intended for users to choose between library and IPC model anymore.
To build Library model, please set TFM_LIB_MODEL to ON.
The TFM_PSA_API=ON can be kept as is for the time being.
So there would be impacts wherever Library Model is used.
Please get prepared.
Thanks.
Best Regards,
Kevin
