Re: [TF-M] TFM and FreeRTOS

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@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: Friday, May 3, 2019 9:36 AM To: tf-m@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@arm.com Sent: Tuesday, April 30, 2019 5:19 PM To: Andrej Butok andrey.butok@nxp.com; tf-m@lists.trustedfirmware.org Cc: nd nd@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@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@arm.com Cc: TF-M@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@arm.com Sent: Thursday, April 25, 2019 11:26 AM To: Andrej Butok andrey.butok@nxp.com; tf-m@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@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... -- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...