- TF-M - lists.trustedfirmware.org

Re: [TF-M] [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment

by DeMars, Alan

In order to pass along the new ‘type’ argument in psa_call, it seems that this line in tfm_svcalls.c: msg = tfm_spm_create_msg(service, handle, PSA_IPC_CALL, ns_caller, invecs, in_num, outvecs, out_num, outptr); Should be: msg = tfm_spm_create_msg(service, handle, type, ns_caller, invecs, in_num, outvecs, out_num, outptr); Otherwise the receiving SP will always see msg.type == PSA_IPC_CALL. Alan From: Summer-ARM (Summer Qin) [mailto:noreply@developer.trustedfirmware.org] Sent: Thursday, July 25, 2019 7:14 PM To: DeMars, Alan Subject: [EXTERNAL] [Maniphest] [Closed] T435: PSA APIs alignment Summer-ARM closed this task as "Resolved". TASK DETAIL https://developer.trustedfirmware.org/T435 EMAIL PREFERENCES https://developer.trustedfirmware.org/settings/panel/emailpreferences/ To: Summer-ARM Cc: edison-ai, matetothpal, adeaarm, wmnt, ashutoshksingh, KenLSoft, Summer-ARM, akiannillo, ademars, zhengwang721, BabaYB, karl-zh, shebuk, zbh, qixiang, DarshpreetSabharwal, jamesking1, mmorenobarm, abhishek-pandit

6 years, 3 months

1
0
0 0

[RFC] Remove Isolation level 3

by Edison Ai (Arm Technology China)

Hi, There are a series of patches under "remove_isolation_level_3" topic: https://review.trustedfirmware.org/#/q/topic:remove_isolation_level_3+(stat… aim to remove isolation level 3 (TFM_LVL=3) from the library model. These patches will not affect curent isolation level 1 and level 2 for both library model and IPC model. Please help to review them and give comments if you find any problems or anywhere need to enhancement. Thanks, Edison

6 years, 3 months

1
0
0 0

Re: [TF-M] Adding a platform specific tfm_svc_number_t

by Andrej Butok

Just another use-case, FreeRTOS is using the non-secure SVC. It does not expect that it may be used by somebody else (not RTOS). Ideally, if TFM will not occupy SVC. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, July 26, 2019 3:49 AM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t Hi Alan, Can you share us your usage details? This could help us on defining the svc number things you mentioned. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Friday, July 26, 2019 6:59 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Adding a platform specific tfm_svc_number_t > > I need to define platform specific SPM APIs that will be invoked by our SPs. > > Is there a convention for 'cleanly' adding platform specific SVC > enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as > platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C42c1df29f3b84ac62f5708d7116b749e%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636997025530401902&sdata=vO0tq34jt > zFFn9D3cnrDP3a4fnrkq4h5jvzZmob2HnU%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 3 months

1
0
0 0

Adding a platform specific tfm_svc_number_t

by DeMars, Alan

I need to define platform specific SPM APIs that will be invoked by our SPs. Is there a convention for 'cleanly' adding platform specific SVC enumerations to the tfm_svc_number_t typedef in tfm_svc.h as well as platform specific 'case's to SVCHandler_main() and/or SVC_Handler_IPC()? Alan

6 years, 3 months

1
0
0 0

Uniform Secure Service Signature

by DeMars, Alan

With the introduction of the 'type' argument in psa_call(), will the 'Uniform Secure Service Signature' also be updated to include 'type' as its first argument? https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Alan

6 years, 3 months

1
0
0 0

Re: [TF-M] PSA API prototype update

by DeMars, Alan

When do you anticipate that this patch will be merged to master? -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, July 23, 2019 11:17 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] PSA API prototype update Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

2
3
0 0

PSA API prototype update

by Ken Liu (Arm Technology China)

Hi, A patch is pushed for couple of days reveals the update on PSA API prototype and its related caller change: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1572 The most obvious part is a new parameter member 'type' is introduced in 'psa_call'. This is the first step of our upgrading to the latest PSA Firmware Framework Specification. The API internal behavior would come step by step later and now we can call PSA FF API in 1.0.0 prototypes. The callers included in TF-M has been updated in this patch. Developers who developed extra services should mention this change and update PSA API related sources. Any feedback please comment under the patch, or reply to this mail thread. Thanks. -Ken

6 years, 3 months

1
0
0 0

TF-M Internal Trusted Storage service design proposal

by Jamie Fox

Hi all, As you may be aware, implementing the PSA Internal Trusted Storage (ITS) APIs is on the TF-M roadmap for this quarter (https://developer.trustedfirmware.org/w/tf_m/planning/). We plan to implement these APIs with a new TF-M Internal Trusted Storage service. The design proposal for the new TF-M ITS service is now available for design review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 . The design is currently in "draft" state, which means further refinements are to be expected, and feedback is welcome. For more information about the PSA ITS APIs themselves, the PSA Storage API document may be downloaded from here: https://pages.arm.com/PSA-APIs Kind regards, Jamie

6 years, 3 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations * If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. * If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 1. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

6 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M