- TF-M - lists.trustedfirmware.org

Re: [TF-M] [ATTENTION] SPM Update: Secure Partition build flag 'CONFIG_TFM_BUILDING_SPE' required.

by Ken Liu

Hi everyone, If you are creating out-of-tree partitions, please assign c-flag 'CONFIG_TFM_BUILDING_SPE' to the partitions sources. The reason is that FFM client header is used by both SPE and NSPE clients, and SPE would support multiple ABI methods and these methods can co-exist in the system, this flag can help the partition to choose correct ABI for FFM API. Check here for an example: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11897/11/sec… Or do you think choosing one ABI as the default ABI (default ABI owns the spec originally defined symbols) should work? Any comments please feel free to raise. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, October 20, 2021 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [ATTENTION] SPM logic is under significant updating before End of Oct Hi, To support FFM 1.1 features (SFN mainly), the SPM logic is under significant updating till End of Oct, please: - If you are doing release-targeted development, please based on the released tags. - If you are developing with the latest master branch, please report bugs met. Our plan is to collect all bugs and fix them after this update, before the next release. - Keen to receive your fixes and contributions. It would be very nice if you can do these. All patches would go as a usual process, hence it should work for most of the configurations, except those not covered by the automation test. The platform related interfaces are not changing, hence no worry for platform owners. Thanks! /Ken

3 years, 2 months

1
0
0 0

Re: [TF-M] Sending events from TF-M to non-secure world?

by Li, Jun R

Hi Ken, Thanks for the suggestions! Actually on the chip we are using (Nordic SoC), there is an event generator unit we can use directly without the needs to do hardware changes. I would like to try that approach. The reason we can't do polling is that the events are generated during the enrollment process. I don't think that our biometric secure partition is reentrant while a process is onging, right? It is using just the single thread model. Regards, Jun Message: 1 Date: Wed, 20 Oct 2021 05:43:23 +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] Sending events from TF-M to non-secure world? Message-ID: <DB9PR08MB676161D704B2D3D861283E6CF5BE9(a)DB9PR08MB6761.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Jun, To trigger an interrupt by software, Register 'STIR' may help you. The scenario you are describing is a practical use case hence it makes sense to think more about it. The scenarios you are describing is more related to the programming model - As the SPE is working more like a library, the NS caller polling the status of secure services by service interfaces and updating local presenting are more straight (and simple). And if you have involved a callback/event-based programming model into your secure service already (3rd party provided such a library, e.g.), you'll have to invent some mechanism to interactive with NS. From the Firmware Framework - M perspective, the peripheral is private to a partition, you can treat shared peripheral/memory as private resources to this partition, claim it in the manifest, and use it to communicate with NS. This shared peripheral (Aka MMIO in the specification) is private, it cannot be shared with other partitions. More comments? BR. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 10:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Sending events from TF-M to non-secure world? Hi Ken, Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution? Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good? Regards, Jun On 10/19/21, 00:23, "TF-M on behalf of tf-m-request(a)lists.trustedfirmware.org" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m-request(a)lists.trustedfirmware.org> wrote: Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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: Sending events from TF-M to non-secure world? (Ken Liu) 2. Inline asm syntax unified and symbol reference in IAR toolchain (Ken Liu) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Oct 2021 02:06:35 +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] Sending events from TF-M to non-secure world? Message-ID: <DB9PR08MB67613655A2ACA207C751C791F5BD9(a)DB9PR08MB6761.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Jun, Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels. Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns. If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks. The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 12:20 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Sending events from TF-M to non-secure world? Hi, Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way. Appreciate any comments or suggestions! Jun Intel Corporation @ SC, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff875…> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

3 years, 2 months

1
0
0 0

Re: [TF-M] Supporting encryption with ITS

by Vasilakis, Georgios

Hey Andrew, These are very valuable points! For us I think that we aim mainly for per key integrity and confidentiality on the key material and integrity only for the key metadata. Providing confidentiality for the whole keystore will need major changes in the PSA APIs and will be out of scope for us. Providing per key confidentiality for the key material is a very straightforward change as you described. ITS will not need to change at all in this case, we will only modify the PSA crypto APIs. Providing per key integrity for key metadata will need a bit more thinking since apart from the fields included in the psa_persistent_key_storage_format we will also need the fields from the psa_storage_info_t struct but this should not be a serious issue as well. To conclude I think that we need to design the changes so that it is possible for platforms to implement these two requirments but we don't need to enforce them. I think that we need to have the flexibility to allow platforms to make their decisions on what they want to support depending on their needs. If, for example, a platform wants to support only confidentiality on the key material, they should be able to do that in my opinion. Since we are discussing platform specific implementations, the IV or any additional data needed could be probably stored (hidden to the PSA APIs) inside a platform specific struct inside the psa_persistent_key_storage_format struct. This will minimize the storage requirements for each platform. Regards, George ________________________________ From: Kvamtrø, Frank Audun <frank.kvamtro(a)nordicsemi.no> Sent: Wednesday, October 20, 2021 3:13 PM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no> Subject: Vs: [TF-M] Supporting encryption with ITS ________________________________ Fra: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> på vegne av Andrew Thoelke via TF-M <tf-m(a)lists.trustedfirmware.org> Sendt: onsdag 20. oktober 2021 10:31 Til: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Kopi: nd <nd(a)arm.com> Emne: Re: [TF-M] Supporting encryption with ITS Hi, Note that, by specification, ITS must provide confidentiality, integrity and replay protection for the data stored within it. However, if the platform already provides that protection via isolation/logical/physical mechanisms, then adding cryptographic protection provides some defence in depth, or may mitigate some forms of physical attack. In this case, it is not obvious what forms of cryptographic protection are needed, as cryptography is not providing the primary security properties for the ITS data. As a result, I think the best design for this requirement will depend on the details of the protection that is required. In this use case, which of the following types of cryptographic protection are needed: 1. Confidentiality of key material (the actual bits of the key data) 2. Confidentiality of key material and key metadata 3. Confidentiality of the full keystore 4. Per-key Integrity of key material 5. Per-key Integrity of key material and key metadata 6. Per-key Confidentiality and Integrity of key material and key metadata 7. Confidentiality and integrity of the full keystore 8. Rollback protection? Per-key confidentiality, or confidentiality+integrity would be reasonably straight-forward to implement in a layer over the simple ITS storage – but would probably add IV or nonce+tag data to each key stored (assuming a HUK-derived encryption key is used). For just encryption, given the pseudo-random nature of secret keys – it might be possible to drop the need for random IV (and just use the client id + key id as an IV/nonce). Full key store confidentiality or confidentiality+integrity requires much more complex design, as this aims to conceal and protect the identity of the keys that are stored, not just the key material and/or key metadata. Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vasilakis, Georgios via TF-M Sent: 19 October 2021 14:31 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Supporting encryption with ITS Hello again, sorry for the second email by my formatting got lost in the first one unfortunately. Let me include the formatted context below: Following the discussion regarding the encryption with ITS let's discuss a bit further the ideas discussed in the meeting. 1)Allow the protected storage to be used as a storage backend for persistent key storage in PSA crypto: This introduces the problem of reentrance that we discussed before. We cannot call crypto from the inside the PSA storage partition (either ITS of PS if we wanted to switch) 2)Do the encryption in the crypto partition instead of the ITS: This will require to create some platform specific encryption abstraction since we cannot have reentrance in PSA crypto as well. Meaning that we cannot call PSA crypto from PSA crypto. The main thing that needs to be solved in this solution is where can we store the metadata. The key itself can be derived from the HUK and does not need to be stored but the metadata need to be stored. These metadata can be stored by expanding the psa_storage_info_t struct or by introducing a new struct. The crypto storage apis will need to be modified to be aware of the extra information and handle them. 3)Put a frontend to ITS so that we select specific keys that need to be derived by the HUK. This is like the idea 2 I think in a concept level. The previous two designs described in the mailing list was to refactor the ITS and the PS partitions to have a common "encryption" library and the idea of refactoring the ITS itself to have an encryption layer. I personally prefer the solution 2 more than the other solutions. Moving the encryption in a higher level and using the ITS as a simple storage solution seems a cleaner approach. This will introduce a crypto abstraction layer (different than PS) but I don't consider it as a major disadvantage since all the crypto implementations in this scope will be very platform specific. Let me know about your opinions on this, if there are no major objections, I am willing to design a solution and some header files to elaborate more on this design. ________________________________ From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Tuesday, October 19, 2021 3:18 PM To: 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 Hello all, Following the discussion regarding the encryption with ITS let's discuss a bit further the ideas discussed in the meeting. Allow the protected storage to be used as a storage backend for persistent key storage in PSA crypto: This introduces the problem of reentrance that we discussed before. We cannot call crypto from the inside the PSA storage partition (either ITS of PS if we wanted to switch) Do the encryption in the crypto partition instead of the ITS: This will require to create some platform specific encryption abstraction since we cannot have reentrance in PSA crypto as well. Meaning that we cannot call PSA crypto from PSA crypto. The main thing that needs to be solved in this solution is where can we store the metadata. The key itself can be derived from the HUK and does not need to be stored but the metadata need to be stored. These metadata can be stored by expanding the psa_storage_info_t struct or by introducing a new struct. The crypto storage apis will need to be modified to be aware of the extra information and handle them. Put a frontend to ITS so that we select specific keys that need to be derived by the HUK. This is like the idea 2 I think in a concept level. The previous two designs described in the mailing list was to refactor the ITS and the PS partitions to have a common "encryption" library and the idea of refactoring the ITS itself to have an encryption layer. I personally prefer the solution 2 more than the other solutions. Moving the encryption in a higher level and using the ITS as a simple storage solution seems a cleaner approach. This will introduce a crypto abstraction layer (different than PS) but I don't consider it as a major disadvantage since all the crypto implementations in this scope will be very platform specific. Let me know about your opinions on this, if there are no major objections, I am willing to design a solution and some header files to elaborate more on this design. Regards, George ________________________________ From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Wednesday, September 29, 2021 2:04 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> <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 the feedback! Does the storage area on your device meet this requirement? Yes, our devices can secure against read and write access through the dedicated peripherals (SPU + MPU). Is the memory physically isolated? If by that you mean if they are located outside of the chip then it is not. It is part of the package. If not, I wonder why not uses the Protected Storage service instead? The reason that we cannot use the protected storage service is that it is not supported as a storage backend by the PSA crypto APIs. Storing non-volatile keys right now using the PSA APIs uses ITS as a storage backend. Your comments regarding storing the IV and the TAG in Protected Storage are, of course, valid. If we decide to use a common code base we will have to do changes in the design of both services to overcome these issues. Overall, the motivation for encrypted ITS is based on the raising popularity of hardware-based attacks. The fact that right now we provide all the security measures needed does not mean that nothing will get compromised in the future. A security in depth approach seems more reasonable for such sensitive data. I am happy to join the TF-M Tech forum this Thursday and discuss it further, yes! Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Tuesday, September 28, 2021 12:20 PM 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, 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

3 years, 2 months

1
0
0 0

Technical Forum call - October 28

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, October 28, 15:00-16:00 UTC (US time zone). That session Chris Reed kindly agreed to present "Introduction to pyOCD" - the method to program and debug TF-M and Cortex-M MCUs, in general, using the open-source tool https://pyocd.io/ 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
0
0 0

CMAKE library dependency trace tool for TF-M

by Jianliang Shen

Hi all, I'd like to introduce a CMAKE library dependency trace tool to you. This python script can * Search a specific library's dependent libraries and to-be-linked libraries in a list of repo paths. * Draw a diagram to show the link relationship. * Give some other information about: * Include paths * Source files * Compile definitions The main feature of diagram is similar with [CMakeGraphVizOptions]<https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html#cmakeg…>, the differences are: * The new tool can focus on certain library with specific trace depth like 1, 2 and n. * The new tool is not runtime, it is a static search and can search all libraries whose runtime build may be silenced. * The new tool makes the diagram more colourful to be more readable. With this tool, I hope you can get and check the structure of CMAKE library more quickly when developing the code and libraries. I have proposed a patch in tf-m-tools repo: [library dependency trace tool]<https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/12019>. This tool may not be convenient for everyone of you so here I beg for your feedbacks to make it better. Thanks. Best Regards Jianliang Shen

3 years, 2 months

1
0
0 0

[ATTENTION] SPM logic is under significant updating before End of Oct

by Ken Liu

Hi, To support FFM 1.1 features (SFN mainly), the SPM logic is under significant updating till End of Oct, please: - If you are doing release-targeted development, please based on the released tags. - If you are developing with the latest master branch, please report bugs met. Our plan is to collect all bugs and fix them after this update, before the next release. - Keen to receive your fixes and contributions. It would be very nice if you can do these. All patches would go as a usual process, hence it should work for most of the configurations, except those not covered by the automation test. The platform related interfaces are not changing, hence no worry for platform owners. Thanks! /Ken

3 years, 2 months

1
0
0 0

Re: [TF-M] Sending events from TF-M to non-secure world?

by Li, Jun R

Hi Ken, Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution? Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good? Regards, Jun On 10/19/21, 00:23, "TF-M on behalf of tf-m-request(a)lists.trustedfirmware.org" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m-request(a)lists.trustedfirmware.org> wrote: Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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: Sending events from TF-M to non-secure world? (Ken Liu) 2. Inline asm syntax unified and symbol reference in IAR toolchain (Ken Liu) ---------------------------------------------------------------------- Message: 1 Date: Tue, 19 Oct 2021 02:06:35 +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] Sending events from TF-M to non-secure world? Message-ID: <DB9PR08MB67613655A2ACA207C751C791F5BD9(a)DB9PR08MB6761.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Jun, Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels. Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns. If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks. The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details? BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 12:20 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Sending events from TF-M to non-secure world? Hi, Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way. Appreciate any comments or suggestions! Jun Intel Corporation @ SC, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff875…>

3 years, 2 months

2
1
0 0

Re: [TF-M] Enablement of external bl2 builds

by Bohdan.Hunko＠infineon.com

Hi Sherry, So I actually checked issue from last mail ‘When building TFM with CRYPTO_HW_ACCELERATOR=ON and BL2=OFF I am getting this error:’ and turns out everything is fine in master branch, that error is only present in my local branch due to changes I have made. I am glad we have one bug less 😊 Sorry for wrong report. 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> From: Hunko Bohdan (CSUKR CSS ICW SW FW) Sent: 01 October 2021 12:49 To: Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko(a)infineon.com>; Sherry.Zhang2(a)arm.com; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com> Cc: nd(a)arm.com Subject: RE: Enablement of external bl2 builds Hi all, One more thing on this topic. There is one more issue with building TFM without BL2. When building TFM with CRYPTO_HW_ACCELERATOR=ON and BL2=OFF I am getting this error: CMake Error at platform/ext/accelerator/CMakeLists.txt:11 (add_library): No SOURCES given to target: bl2_crypto_hw So I think this is one more thing that needs to be fixed. 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> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Bohdan Hunko via TF-M Sent: 30 September 2021 17:34 To: Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>> Cc: nd(a)arm.com<mailto:nd@arm.com> Subject: Re: [TF-M] Enablement of external bl2 builds Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Sherry, Thanks for patching MCUBOOT_IMAGE_NUMBER issue. It was one of the issues we faced with. I also agree that mcuboot_config.h should be taken from our BL2 repo. So no changes needed there. About porting files (tfm/bl2 folder). We are planning to use existing porting files. But as you said currently they are not included into the build because BL2=0. So this needs to be fixed to include these porting files when TFM_PARTITION_FIRMWARE_UPDATE is ON. One minor issue we have is BOOT_DATA_AVAILABLE currently it is only defined if BL2=1 and MCUBOOT_MEASURED_BOOT=1. See this line of code<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. I think we can either change that line of code or we can defile BOOT_DATA_AVAILABLE in our platform files using add_definitions(-DBOOT_DATA_AVAILABLE). First way is a bit harder but I thinks it fits better into TFM architecture. Second way is easier but it seems more like workaround than like solution. Do you have any suggestions about this problem? We are not blocked by these issues, so no worries here. 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> From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: 30 September 2021 11:38 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Tkachov Kostiantyn (CSUKR CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>>; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>>; Kytsun Hennadiy (CSUKR CSS ICW SW FW) <Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com>>; Hunko Bohdan (CSUKR CSS ICW SW FW) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Enablement of external bl2 builds Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, I tried to build TF-M with FWU service without BL2 with the following command(FWU enabled with shared data while no BL2): cmake -S . -B cmake_build -DTFM_PLATFORM=arm/musca_b1/sse_200 -DCRYPTO_HW_ACCELERATOR=OFF -DPLATFORM_DUMMY_NV_SEED=ON -DBL2=0 -DMCUBOOT_PATH=../mcuboot The following issues I met: 1. Build time error by that ` MCUBOOT_IMAGE_NUMBER ` is passed as an empty macro into the flash_layout.h I have created a patch to fix it. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11729 1. Build error in ` bootutil_public.c `. The mcuboot_config.h which is generated automatically when the BL2=ON is not found. Also the files( in tf-m/bl2 folder) about porting MCUboot into TF-M is not found by the build system as BL2=0. For the config file, I think, it should be imported from your specific MCUboot repo as it is generated when BL2 image is built. For the MCUboot porting files, are you using the files under tf-m/bl2 folder or using your specific porting files? The FWU service needs the porting source files. See code at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…. Are your blocked by these two issues? Can you share the detailed issue you met if there is more? Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Bohdan Hunko via TF-M Sent: Tuesday, September 28, 2021 6:44 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Kostiantyn.Tkachov(a)infineon.com<mailto:Kostiantyn.Tkachov@infineon.com>; Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>; Hennadiy.Kytsun(a)infineon.com<mailto:Hennadiy.Kytsun@infineon.com> Subject: [TF-M] Enablement of external bl2 builds 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

2
3
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

Announcement: documentation build is separated from the main.

by Anton Komlev

Hello, >From now on, documentation has no interference with the main build and runs as an independent CMake project. This reduces CMake configuration phase and not requires doc tools for the normal development anymore. There are no changes for building the binaries, but documentation build shall start in the docs folder cmake -S docs -B build_docs cmake --build build_docs More details are here: https://tf-m-user-guide.trustedfirmware.org/docs/technical_references/instr… Thanks, Anton

3 years, 2 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M