September 2021 - TF-M - lists.trustedfirmware.org

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

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

2 years, 3 months

6
16
0 0

Deprecation of ARM/MPS2/fvp_sse300 platform

by Anton Komlev

Hi Everyone, I would like to propose the deprecation of arm/mps2/fvp_sse300 platform because the main platform for Corstone-300 is MPS3, available in arm/mps3/an547 and we would like to reduce the number of the platforms to maintain. Following the deprecation process, https://tf-m-user-guide.trustedfirmware.org/platform/ext/platform_deprecati… this proposal is open for discussion at least for 4 weeks before the platform will be marked as deprecated and removed from TF-M unless any objection received. Thanks and Best regards, Anton Komlev

3 years, 2 months

1
1
0 0

Platform specific test out-of-tree build

by Jianliang Shen

Hi all, Thanks for Chris Brand's enhancement suggestion about platform-specific tests. I'm enabling out-of-tree build mode of platform specific test suites with tf-m-tests. Currently I have proposed the following changes: * [TF-M patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11296>] * [tf-m-tests patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/11297>] My proposal supplies a flexible interface for partners to out-of-tree build local tests. With this new feature, * Partners can perform local test quickly during development to improve test efficiency * Partners can maintain local test code outside tf-m-tests repo in case of confidential information or IP issues. I also put an out-of-tree example test source code into tf-m-extras repo and a document in TF-M repo: * [tf-m-extras patch<https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/11323>] * [TF-M patch doc<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11336>] This example indicates that platform-specific tests can be integrated with tf-m-tests, without following tf-m-tests structure or definitions. The document introduces the usage and coding guide of this new feature. PS: If partners would like to upstream platform specific test code, we will be glad to create a specific folder under tf-m-tests repo as Chris Brand suggested. I'd be grateful if you can take a look at the patch sets above. Any suggestion or comment is welcome. Best Regards Jianliang Shen

3 years, 2 months

1
2
0 0

nxp/lpcxpresso55s69 builds broken

by Thomas Törnblom

While verifying that my Musca B1/S1 fixes for IAR did not break other targets I ran into building problems for the nxp/lpcxpresso55s69 for both gnuarm and iararm. I've tested with the following cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=nxp/lpcxpresso55s69 "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DTFM_PSA_API=ON -DBL2=OFF Fails with: d:/apps/gnuarm/10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\thomasto\Projects\tf-m12\trusted-firmware-m\gnuarm/../secure_fw/spm/ffm/psa_api.c:890: undefined reference to `tfm_hal_irq_disable' I notice that tfm_hal_irq_disable() is guarded by: #if TFM_LVL == 3 in .../nxp/common/tfm_hal_isolation.c, while the other targets does not have this guard. What isthe reason for that? Trying to set that with cmake causes other failures. commit 8444011d works commit 4051016f fails I tried bisecting between these two commits, but the builds run into other build failures so I gave up on that. Is his a known issue? I have successfully built and run regression tests on musca b1, musca s1, psoc64 and I have built, but not run an519, an521, an524 Cheers, 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>

3 years, 2 months

2
2
0 0

Enablement of external bl2 builds

by Bohdan.Hunko＠infineon.com

Hi everyone, When adding support for new platform we ran into an issue with BL2 variable. In our architecture we have Bootloader based on MCUboot (aka BL2) but we are not planning to build it with TF-M. Bootloader would be separate repo and be built separately. So we need the way to build TF-M with FWU service and shared data definitions when BL2=OFF. I was trying to add support for this but was not able to do this because build structure is quite complicated. Does anyone have ideas or suggestions about the way we can implement this feature? 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>

3 years, 2 months

3
3
0 0

Technical Forum call - Sep 30

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Sep 30, 15:00-16:00 UTC (US 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

3 years, 2 months

1
1
0 0

[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

3 years, 2 months

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)

3 years, 2 months

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

3 years, 2 months

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

3 years, 2 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M September 2021