- TF-M - lists.trustedfirmware.org

Re: [TF-M] Trusted boot - rollback protection

by David Brown

On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote: >Please see the following link for a design proposal on anti-rollback protection in trusted boot: > >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Somewhat related, as I've been working through a prototype implementation of SUIT, the SUIT manifest also wants what they call a "sequence number", which is a monotonically increasing number associated with each version. They've kind of decided they don't want to have to do anything like semantic version parsing as part of the firmware upgrade. I think this sequence number serves the same purpose as this security counter (except that the sequence number is required to increase with each software relase). One of the goals of the MCUboot community is to make sure that however the SUIT manifest is implemented, it must be semantically the same as the existing TLV-format manifest. An easy solution is to just treat the existing version as a 32-bit number (ignoring the build-id, which I think is supposed to be the case, anyway). As far as the possibility of re-using the same security counter value, I don't think that is something that should be done. In general, it isn't possible to know where security bugs will be found in an image. If we always increase the security counter value, someone still running the immediately following image will be prevented from rolling back to the version with the security flaw, whereas if we reused the values, it might be necessary to try to force them to upgrade to a new version that has the counter increased. Also, I think it is important to clarify that the security counter is not required for anti-rollback, it only protects the anti-rollback implementation from a specific threat: something that is able to replace the primary firmware image outside of the control of the bootloader. The cost is that implementing a security counter generally requires specific hardware just for that purpose. An entirely software anti-rollback protects against other threats, including the common case of using the ordinary firmware upgrade process. David

6 years, 2 months

2
3
0 0

Re: [TF-M] TFM and FreeRTOS

by Andrej Butok

Hello, So, the RTX was replaced by FreeRTOS (regression and psa-tests passed). Required changes: 1) Use CMSIS-FreeRTOS adapter from: https://github.com/ARM-software/CMSIS-FreeRTOS 2) Do not call os_wrapper_join_thread()/osThreadJoin() and do not use osThreadJoinable flag. It is not supported by FreeRTOS 3) Add missing osThreadExit(). 4) Add osDelay(1) to tfm_sst_run_test(), as FreeRTOS free some allocated resources only in the idle task. 5) Disable TFM_NS_CLIENT_IDENTIFICATION to avoid SVC conflict. 5) Other minor changes. Proposals for general TFM code: 1) Delete os_wrapper_join_thread()/osThreadJoin() as it is optional. It works without it and not supported by all RTOSes. 2) Add missing osThreadExit() to test_task_runner(). 3) Do not call each SST test in separate task, or to allow switching to idle task after each SST test. 4) Find other TFM_NS_CLIENT_IDENTIFICATION mechanism, which will not use SVC. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, May 3, 2019 9:36 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hello, So, even if the unique User ID is optional, it is mandatory for the case when different NS users must have different security asset policies for SST resources. Is it possible to find another mechanism for the user ID assignment which does not use SVC? To avoid unwanted limitation for FreeRTOS and any other NS application using SVC. Thanks, Andrej -----Original Message----- From: Miklos Balint <Miklos.Balint(a)arm.com> Sent: Tuesday, April 30, 2019 5:19 PM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] [EXT] Re: TFM and FreeRTOS Caution: EXT Email Hi Andrej, Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1). That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services. This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections." Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4. Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one. Let me know if you need further assistance in this matter. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 25 April 2019 12:47 To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hi David, OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API. In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION. It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID. What does it mean? How does it limits the functionality? Is it OK from PSA point of view? Thanks, Andrej -----Original Message----- From: David Hu (Arm Technology China) <David.Hu(a)arm.com> Sent: Thursday, April 25, 2019 11:26 AM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Subject: [EXT] Re: [TF-M] TFM and FreeRTOS Caution: EXT Email Hi Andrej, I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following. In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does. FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities. By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core. Hope it can hlep you. Best regards, Hu Ziji On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote: > Hello, > > Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? > I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. > > Thanks, > Andrej > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 2 months

1
0
0 0

Fixing implicit casting of C enumeration in TF-M: design document

by Hugues De Valon

Hi All, Please find under the following link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1040 the review of a design document which aim is to fix the implicit casting happening with enumerations in TF-M. Feel free to add any comments you want on the review! Kind regards, Hugues IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 2 months

1
0
0 0

TF-M Crypto service design document

by Antonio De Angelis

Hi all, I have uploaded the design document for the TF-M Crypto service at the following Gerrit code review in RST format: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1023 It can be possible to render the HTML format of the design document by checking out the patch above and build the docs (in particular, by building the install_userguide target) Comments are welcome, here in this thread or preferably in the Gerrit review for better tracking. Thanks, Antonio

6 years, 2 months

1
0
0 0

SST 512B write support?

by Andrej Butok

Hello, Current TFM SST service supports 1, 2, 4 and 8 Byte minimum write. Do you have any plan to add the 512 Byte minimal write support to the TFM SST? LPC55S69 Flash has the 512Bytes program size. Guess, all flash modules with ECC has the same requirement. Thanks, Andrej Butok

6 years, 2 months

1
0
0 0

Update to contribution guide

by Ashutosh Singh

Hi, Contribution guide has been updated to reflect current way of working. More details have been added to clarify the steps. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1007/ Feedback welcome and appreciated! Thanks, Ashu

6 years, 2 months

1
0
0 0

Re: [TF-M] FW: Trusted boot - rollback protection

by David Brown

On Mon, Apr 15, 2019 at 02:52:56PM +0000, Tamas Ban via TF-M wrote: >Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). > >The image signature cover these continues blocks in memory: >- image header >- image >- some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) > >Because these are contiguous regions in the memory it is not possible >to place only the (header + TLV section) to the trusted memory but >miss out the image itself (at least I cannot see how to solve) Could the trusted memory contain a version field, and perhaps a hash of the image? David

6 years, 2 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM and FreeRTOS

by Miklos Balint

Hi Andrej, Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1). That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services. This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections." Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4. Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one. Let me know if you need further assistance in this matter. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 25 April 2019 12:47 To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hi David, OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API. In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION. It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID. What does it mean? How does it limits the functionality? Is it OK from PSA point of view? Thanks, Andrej -----Original Message----- From: David Hu (Arm Technology China) <David.Hu(a)arm.com> Sent: Thursday, April 25, 2019 11:26 AM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Subject: [EXT] Re: [TF-M] TFM and FreeRTOS Caution: EXT Email Hi Andrej, I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following. In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does. FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities. By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core. Hope it can hlep you. Best regards, Hu Ziji On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote: > Hello, > > Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? > I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. > > Thanks, > Andrej > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

2
1
0 0

Re: [TF-M] Avoid osThreadJoin()

by Jamie Fox

Hi Andrej, The idea of the OS wrapper layer is to abstract the underlying OS, so that the test app can use generic wrapper APIs, which are implemented using OS-specific APIs. In os_wrapper_rtx.c, we provide an example implementation that targets the CMSIS-RTOS2 APIs for RTX. As osThreadJoinable is not supported by FreeRTOS, you can remove that attribute in your port, and implement os_wrapper_join_thread() as a no-op. We use semaphores for synchronisation in the test app anyway, so os_wrapper_join_thread() only needs to be implemented if threads are joinable and so need join() to be called to free up resources associated with the thread. I do think we could make the OS wrapper layer a bit more generic though. We could replace the only call to os_wrapper_join_thread() that currently exists with a call to a new function os_wrapper_delete_thread(), which is defined to release the resources associated with a thread context. For CMSIS-RTOS2 this can be empty because this happens automatically, but for other RTOS APIs there may be some delete() function that needs to be called. Let me know what you think. Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 02 May 2019 15:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Avoid osThreadJoin() Hello, The TFM test applications are using CMSIS-RTOS2 API. And this is good. But could you delete os_wrapper_join_thread()and avoid using of osThreadJoin(). If I understand well, its support by RTOS tasks is optional (via osThreadJoinable flag). The problem is that the osThreadJoin() functionality is not supported by FreeRTOS (https://arm-software.github.io/CMSIS-FreeRTOS/General/html/tech_data.html). It is critical obstacle. Could you tell what are you going to do with this requirement? To understand, if to continue with a FreeRTOS port. Thank you Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Avoid osThreadJoin()

by Andrej Butok

Hello, The TFM test applications are using CMSIS-RTOS2 API. And this is good. But could you delete os_wrapper_join_thread()and avoid using of osThreadJoin(). If I understand well, its support by RTOS tasks is optional (via osThreadJoinable flag). The problem is that the osThreadJoin() functionality is not supported by FreeRTOS (https://arm-software.github.io/CMSIS-FreeRTOS/General/html/tech_data.html). It is critical obstacle. Could you tell what are you going to do with this requirement? To understand, if to continue with a FreeRTOS port. Thank you Andrej Butok

6 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M