- TF-M - lists.trustedfirmware.org

[IMPORTANT: PLATFORM BUILD ISSUE] [REQUIRE PLATFORM ACK] RE: [Request Platform Support] Abstracted MMIO HAL

by Ken Liu

Hi everyone, Being notified by some platform vendors that platforms build breaks in MASTER branch (releases are working well and not affected) due to not integrate with the latest HAL change: The reference link: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036 And these platforms reported build break: Nordic NXP Because of bandwidth issues, we can’t maintain all the platform sources, hence require upstreamed platform owners to take a look at their platform builds and runs ok, and integrate with the updated HAL if it does fail. Please reply to this thread if there are problems and I have created one ticket for tracking this if replying in a thread is more convenient for you: https://developer.trustedfirmware.org/T967 Sorry for the inconvenience made, I should warn all the platform owners in earlier mails – I will validate the build again later in Oct to see if there are still platform breaks and contact the platform code owners to discuss plans. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Friday, September 17, 2021 3:06 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL The MMIO binding patch set are all merged, assume this will simplify the SPM integration much. Follow up fixups will be created if missing comments reported. Anyway, all platform patches are not blocked anymore, feel free to merge the reviewed and CI passed patches. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Friday, September 3, 2021 1:27 PM To: 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] [Request Platform Support] Abstracted MMIO HAL Hi, Another reminder to mention the MMIO binding patches. Several platforms are changed to pass the CI, please platform owners to review the patches, such as: PSOC: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187 STM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11186 Some of other platform patches are created as well. This is a significant change for platform which helps much easier integration. After the first series of patches, the problems not covered by the CI need to be fixed adhoc. Please read the tech forum topic on 2nd Sep for more details or you can just scroll down to check the previous content. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, August 30, 2021 5:18 PM To: 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] [Request Platform Support] Abstracted MMIO HAL The patchset has updated and now CI passed okay: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187 BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Thursday, August 19, 2021 2:16 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Request Platform Support] Abstracted MMIO HAL Hi everyone, The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries. Hence, a deeper abstracted interface are provided. Here are the details: - It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources. - When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this). - A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform. - When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things. - Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved. We created a patch to showcase the usage on AN521: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036 This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable. Now come to the request: Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms. Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform. Any feedbacks are welcome. Thank you very much! /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 1 month

8
11
0 0

NSID improvement patches are in review

by David Wang

Hi, Believe you still remember I shared the non-secure client ID management update in tech forum<https://www.trustedfirmware.org/meetings/tf-m-technical-forum/> a few months ago (slides<https://www.trustedfirmware.org/docs/Non_Secure_Client_ID_management_update…>, video<https://linaro-org.zoom.us/rec/share/k7vJnf8qcugoRNxu5hRSyc0thzSTbTT295ZLyy…> (passcode: dqHBI$2z)). The patches and document are available in tf.org for public review. The integration reference and test suite are also provided. If you're using SPM to manage the NSID (fixed `-1` for all NS connections) which is the default option (`TFM_NS_CLIENT_IDENTIFICATION` is OFF), then it basically won't affect you (if you don't play with `TFM_NS_CLIENT_IDENTIFICATION` flag which is changed). NSCE (non-secure client extension) module is introduced to manage the non-secure context in TF-M which includes the NSID as a member. If you have a requirement to support different NSIDs for NS tasks, then it's for that purpose. Patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11288 (add non-secure context management) https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11289 (add NSCE interface API) https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11616 (Doc) https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11294 (Add NSCE support in nspm and build system) RTOS integration reference (based on RTX): https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11290/ (NSID manager example) https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11291/ (TZ API to NSCE API shim layer) A test suite is added. Tip of the test cases: https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11659/ Welcome to comment. Thanks. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142)

4 years, 1 month

1
0
0 0

Proposal to separate vendor components

by Roman.Mazurak＠infineon.com

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.html https://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

4 years, 1 month

2
2
0 0

Request Access To a Board Peripheral for a App RoT - Problem

by Cristiano Rodrigues

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

4 years, 1 month

2
2
0 0

[Ask for review] FPU support in TF-M

by Feder Liang

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

4 years, 1 month

1
0
0 0

Outdated file location in FWU doc

by Bohdan.Hunko＠infineon.com

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>

4 years, 1 month

2
1
0 0

Trouble building Musca S1 with IAR

by Thomas Törnblom

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>

4 years, 1 month

3
3
0 0

Re: [TF-M] Supporting encryption with ITS

by Fabian Schmidt

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

4 years, 1 month

4
4
0 0

TF-M v1.4.1 hotfix have been released

by Anton Komlev

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

4 years, 1 month

1
0
0 0

Re: [TF-M] Supporting encryption with ITS

by Vasilakis, Georgios

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

4 years, 1 month

1
0
0 0

Supporting encryption with ITS

by Vasilakis, Georgios

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

4 years, 1 month

2
1
0 0

Use IPC Model to build by default

by Kevin Peng

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

4 years, 1 month

1
2
0 0

Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL

by Ken Liu

Hi, Another reminder to mention the MMIO binding patches. Several platforms are changed to pass the CI, please platform owners to review the patches, such as: PSOC: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187 STM: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11186 Some of other platform patches are created as well. This is a significant change for platform which helps much easier integration. After the first series of patches, the problems not covered by the CI need to be fixed adhoc. Please read the tech forum topic on 2nd Sep for more details or you can just scroll down to check the previous content. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, August 30, 2021 5:18 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Request Platform Support] Abstracted MMIO HAL The patchset has updated and now CI passed okay: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187 BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Thursday, August 19, 2021 2:16 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Request Platform Support] Abstracted MMIO HAL Hi everyone, The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries. Hence, a deeper abstracted interface are provided. Here are the details: - It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources. - When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this). - A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform. - When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things. - Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved. We created a patch to showcase the usage on AN521: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036 This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable. Now come to the request: Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms. Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform. Any feedbacks are welcome. Thank you very much! /Ken

4 years, 1 month

5
6
0 0

memory_region_limits structure contents

by Bohdan.Hunko＠infineon.com

Hi everyone, I was wondering is there any reasons to use REGION_NAME(Load$$LR$$, LR_NS_PARTITION, $$Base) declared in this code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> and used here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>? >From code in common linker script<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> I can see: Load$$LR$$LR_NS_PARTITION$$Base = NS_PARTITION_START. So the question is: why regions are used instead of simply using NS_PARTITION_START? And the follow up questions is: do platforms that are built in IPC model (not library model) really need REGION_NAME(Load$$LR$$, LR_VENEER, $$Base)in memory_region_limits memory_regions struct, or that could be just dummy value? 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>

4 years, 1 month

2
2
0 0

Move MCUBoot configs to bl2 specific config file

by Jianliang Shen

Hi all, We decide to move MCUBoot specific configurations to TF-M/bl2/ext/mcuboot folder. This change is to decouple MCUBoot and TF-M configurations and make default_config.cmake clearer. I have proposed the patch set: * [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10560>] I'm grateful to receive any suggestion or enhancement from you. Best Regards Jianliang Shen

4 years, 1 month

1
1
0 0

Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M

by David Hu

Hi all, I'd like to merge the following patch set tomorrow, if there is no more major comment. * Decouple tf-m-tests specific config setting from trusted-firmware-m. [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11167>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11169>] * Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log. [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11153>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11131/>] After the above patches are merged, there are two major changes: * tf-m-tests dedicated configuration setup process will be moved to tf-m-test repo, from TF-M. Therefore you can update tf-m-tests config setting, without modifying TF-M repo. * Tf-m-tests commit ID is specified in TF-M `lib\ext\tf-m-tests\repo_config_default.cmake`, rather than in TF-M main `config_default.cmake`. You can update tf-m-tests commit ID in TF-M without touching the large `config_default.cmake`. Any suggestion or comment is always welcome! Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, August 24, 2021 5:33 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Decoupling tf-m-tests from TF-M Hi all, As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo. The purpose of the decoupling enhancement includes: * Making it more easier to integrate TF-M and port tf-m-tests * Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system. * Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test. Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M. So far we have proposed the following major changes: * Decouple tf-m-tests specific config setting from trusted-firmware-m. [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11167>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11169/1>] * Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10647>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10556>] More patch sets for decoupling are under review as well. * Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log. [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11153>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11131/3>] * Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11181>][tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11182>] I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome. If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me. Thanks in advance. Best regards, Hu Ziji

4 years, 1 month

2
4
0 0

Adding tfm_mailbox_config.h to .gitignore

by Bohdan.Hunko＠infineon.com

Hello everyone. After building the project interface/include/multi_core/tfm_mailbox_config.h is generated, but it is not in .gitignore I think this file should be in .gitignore because it is build artifact and is really annoying to deal with. Am I wrong somewhere? 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>

4 years, 1 month

2
4
0 0

Remove some platform specific test cases

by Shawn Shan

Hi all, We are going to remove some test cases in tfm_core_test. They are: * TFM_INTERACTIVE_TEST * TFM_PERIPH_ACCESS_TEST The main reasons is that these peripheral and interactive test cases are mainly platform specific(button and LEDs), rather than test the main features and secure functionalities of TF-M. Besides, it also a burden for flatform owner to support and maintain those test cases. Do you have any concerns for remove those test cases? Best Regards, Shawn

4 years, 1 month

1
0
0 0

Technical Forum call - Sep 16

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Sep 16, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 1 month

3
2
0 0

Re: [TF-M] TF-M Digest, Vol 35, Issue 6

by Michael Thomas

Ken, Hu, I just saw this message now and wanted to give my perspective based on some of the code Renesas has developed. In general, the primary benefits of having enums are return codes are type checking and portability. So of you have a top level application using an API that always returns an error from a defined enum list, then the application can switch to using different implementations of the same API and does not have to change its error handling code etc. However, if you are returning uint32 instead then its likely that different implementations of the same API will have any possible return code making the application non-portable. I think the issue arises when the enum list is not sufficiently well defined so each enum entry ends up acting as a funnel for x number of lower level error code so there is loss of information etc. But w.r.t the line in the TFM coding guide : " Use enumeration for error codes to keep the code readable.", if the objective is just to make the code readable, then you don’t really need an enum for that... you can achieve readability by using #define XYZ_error. I think that will be much harder to maintain particularly in terms of preventing different error codes from being defined to the same value unless we have a common file where all error code are defined for a specific layer. -Michael -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of tf-m-request(a)lists.trustedfirmware.org Sent: Friday, September 3, 2021 4:38 AM To: tf-m(a)lists.trustedfirmware.org Subject: TF-M Digest, Vol 35, Issue 6 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, 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. Re: [RFC] Can we remove the rule to use enum for error code? (Ken Liu) 2. Re: [RFC] Can we remove the rule to use enum for error code? (Andrew Thoelke) ---------------------------------------------------------------------- Message: 1 Date: Fri, 3 Sep 2021 07:54:41 +0000 From: Ken Liu <Ken.Liu(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code? Message-ID: <DBBPR08MB4741B0807FC4ACD9F4466520F5CF9(a)DBBPR08MB4741.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" I am okay to remove it. Even it can be used to check the error types, but some of the developers do typecast on enum which makes the rule no sense. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Friday, September 3, 2021 3:45 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code? Hi all, Probably you didn’t know that there is such a rule in TF-M coding standard<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…>: * Use enumeration for error codes to keep the code readable. Personally, I’d prefer macros to enum, for error codes. * The implicit type casting of enum can be an issue in coding. TF-M has a document<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default. I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊 May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot! Best regards, Hu Ziji -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trus…> ------------------------------ Message: 2 Date: Fri, 3 Sep 2021 08:38:02 +0000 From: Andrew Thoelke <Andrew.Thoelke(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Can we remove the rule to use enum for error code? Message-ID: <DB7PR08MB38651B33CD7BAEB9BF05F0229ACF9(a)DB7PR08MB3865.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi, In my experience, the only significant benefit of using enums is that some debuggers display the symbolic name for a value with the enum type. But, as already mentioned, using enums does not help in parsing logs, or decoding error values in integer variables/registers; particularly when the definition does not provide explicit values for each identifier. In addition, the rules for determining the implicit integer type for an enum type are non-trivial. This results in a lack of transparency when reading or reviewing code with respect to the size of the enum type in a data structure, or the behaviour when converting an enum value to an integer (or back again). This is why the PSA specifications use explicitly sized integer types for types like psa_status_t, and macros to define values of such types. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 03 September 2021 08:45 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Can we remove the rule to use enum for error code? Hi all, Probably you didn’t know that there is such a rule in TF-M coding standard<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…>: * Use enumeration for error codes to keep the code readable. Personally, I’d prefer macros to enum, for error codes. * The implicit type casting of enum can be an issue in coding. TF-M has a document<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default. I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊 May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot! Best regards, Hu Ziji -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.trus…> ------------------------------ Subject: Digest Footer TF-M mailing list TF-M(a)lists.trustedfirmware.org https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of TF-M Digest, Vol 35, Issue 6 *********************************** Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.

4 years, 1 month

2
1
0 0

Unaligned flash read/write is supported in Boot & FWU

by Sherry Zhang

Hi, The following patch enables the flash read/write with unaligned address/cnt for MCUboot and Firmware Update partition. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10947 This patch has been merged and thanks to all who have reviewed on this patch. As this patch can impact the MCUboot booting up on the platforms, if there is any booting up issue on your platform after this commit, do not hesitate to feedback to me. 😊 Thanks, Regards, Sherry Zhang

4 years, 1 month

1
0
0 0

BOOT_TFM_SHARED_DATA_* usage in arm/musca_b1

by Bohdan.Hunko＠infineon.com

Hi everyone! I see definitions of BOOT_TFM_SHARED_DATA_* in platform\ext\target\arm\musca_b1\sse_200\partition\region_defs.h but I don't see any real usage of that memory. I have found TF-M doc<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> that describe usage of shared memory for Firmware Update Service but once again I was not able to find any code that uses that. I would appreciate if someone could point to docs on this or to code that actually uses shared data between BL2 and TF-M SPE. 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>

4 years, 1 month

4
3
0 0

[RFC] Can we remove the rule to use enum for error code?

by David Hu

Hi all, Probably you didn’t know that there is such a rule in TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/docs/contributing/coding_guide.…>: * Use enumeration for error codes to keep the code readable. Personally, I’d prefer macros to enum, for error codes. * The implicit type casting of enum can be an issue in coding. TF-M has a document<https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/desig…> to solve this. * Using macros to define error codes aligns with PSA return code definitions. * Enum makes function and variable definitions longer * Enum may help developers skip writing specific error code values. But it becomes a trouble when you see an error number from log. You might need to count the enum fields one by one. * Error codes for errors are usually negative but enums are positive ones by default. I’d like to propose to remove this rule from TF-M coding standard. But it doesn’t mean that enum shall not be used anymore. I’m wondering if macros for error code in TF-M can be approved as well. 😊 May I know your opinions please? If it is a convention or a good practice to use enum for error codes in security/trusted software, please help point me to the reference. I don’t find one via google. Thanks a lot! Best regards, Hu Ziji

4 years, 2 months

4
4
0 0

Re: [TF-M] TF-M v1.3.0 release - Fault Injection and DPA in line with PSA L3 Certification

by Reed Hinkel

Hello Suresh: How are you? I hope all is well with you! Virtual Linaro Connect Fall is next week and there is a presentation relevant to your question along with some others. As an online event, it is free registration and I am listing here below a few sessions that might be of interest to you related to security and AI inferencing for microcontrollers: https://connect.linaro.org/schedule LVC21F-116 Assessing the effectiveness of MCUBoot protections against fault injection attacks https://events.pinetool.ai/2231/#sessions/67139?referrer%5Bpathname%5D=%2Fs… LVC21F-112 Picolibc: A C Library for Smaller Systems https://events.pinetool.ai/2231/#sessions/67136?referrer%5Bpathname%5D=%2Fs… LVC21F-303 Secure Sensor Data Pipeline https://events.pinetool.ai/2231/#sessions/67174?referrer%5Bpathname%5D=%2Fs… LVC21F-312 TrustedFirmware.org panel discussion https://events.pinetool.ai/2231/#sessions/67183?referrer%5Bpathname%5D=%2Fs… LVC21F-319 TVM for micro targets https://events.pinetool.ai/2231/#sessions/67190?referrer%5Bpathname%5D=%2Fs… I thought you may be interested in the AI as well since there are security implications for trusted AI. All the best! Reed From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Suresh Marisetty via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: "Suresh.Marisetty(a)infineon.com" <Suresh.Marisetty(a)infineon.com> Date: Thursday, September 2, 2021 at 8:23 AM To: Anton Komlev <Anton.Komlev(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M v1.3.0 release - Fault Injection and DPA in line with PSA L3 Certification Hi, I have a question related to the PSA L3 certification and the requirement to support Side-channel and fault injection attacks. I have noted that TFM and MCUBoot does implement some software countermeasures for Fault Injection. However, I am wondering if there is similar implementation support for the Crypto Lib in TFM (or Mbed TLS) with software counter measures for side channel DPA. Needless to say, there are some known best practices for DPA software countermeasures. thanks Suresh Marisetty Infineon Semiconductor Corporation From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, April 9, 2021 6:25 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.3.0 release Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hello, TF-M project released version v1.3.0, tagged as TF-Mv1.3.0. Please take a look into the release notes for the new features and changes: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… The major features: * Support stateless RoT Service defined in FF-M 1.1 * Support Second-Level Interrupt Handling (SLIH) defined in FF-M 1.1 * Add Firmware Update (FWU) secure service, following Platform Security Architecture Firmware Update API * Migrate to Mbed TLS v2.25.0 * Update MCUboot version to v1.7.2 * Add a TF-M generic threat model * Implement Fault Injection Handling library to mitigate physical attacks * Add Profile Large * Enable code sharing between boot loader and TF-M * Support Armv8.1-M Privileged Execute Never (PXN) attribute and Thread reentrancy disabled (TRD) feature * New platforms added * Add a TF-M security landing page * Enhance dual-cpu non-secure mailbox reference implementation This is the first release performed in the OpenCI infrastructure with no single issue encountered. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

4 years, 2 months

1
0
0 0

Re: [TF-M] TF-M v1.3.0 release - Fault Injection and DPA in line with PSA L3 Certification

by Suresh.Marisetty＠infineon.com

Hi, I have a question related to the PSA L3 certification and the requirement to support Side-channel and fault injection attacks. I have noted that TFM and MCUBoot does implement some software countermeasures for Fault Injection. However, I am wondering if there is similar implementation support for the Crypto Lib in TFM (or Mbed TLS) with software counter measures for side channel DPA. Needless to say, there are some known best practices for DPA software countermeasures. thanks Suresh Marisetty Infineon Semiconductor Corporation From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, April 9, 2021 6:25 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M v1.3.0 release Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hello, TF-M project released version v1.3.0, tagged as TF-Mv1.3.0. Please take a look into the release notes for the new features and changes: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… The major features: * Support stateless RoT Service defined in FF-M 1.1 * Support Second-Level Interrupt Handling (SLIH) defined in FF-M 1.1 * Add Firmware Update (FWU) secure service, following Platform Security Architecture Firmware Update API * Migrate to Mbed TLS v2.25.0 * Update MCUboot version to v1.7.2 * Add a TF-M generic threat model * Implement Fault Injection Handling library to mitigate physical attacks * Add Profile Large * Enable code sharing between boot loader and TF-M * Support Armv8.1-M Privileged Execute Never (PXN) attribute and Thread reentrancy disabled (TRD) feature * New platforms added * Add a TF-M security landing page * Enhance dual-cpu non-secure mailbox reference implementation This is the first release performed in the OpenCI infrastructure with no single issue encountered. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

4 years, 2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M