- TF-M - lists.trustedfirmware.org

Re: [TF-M] Platform: Create platform service for pin functions

by Michel JAOUEN

I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/ On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis. As example , I post https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/ Best regards From: Michel JAOUEN Sent: mercredi 10 avril 2019 13:05 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Platform: Create platform service for pin functions Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards

5 years, 9 months

1
0
0 0

Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

by Ken Liu (Arm Technology China)

Hi Both, The intention of doing this is for packing parameters while handling non-secure psa_call(). This function has five parameters, which means the 5th one needs to be put in NS stack. If we extract 5th parameter in veneer function we need to enable non-secure memory accessing for veneer and implement some assembler code there to fetch PSP_NS. To make it simple at first stage we just pack 'psa_invec' and 'psa_outvec' as two inputs of tfm_psa_call_veneer(); that why the two types are invec -- because they really are inputs. This part really causes confuse and need to be discussed if we need to implement more proper way for this. Let's track it in the ticket. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Thursday, April 11, 2019 6:31 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? > > Hi Alan, > > I think you're right, the prototypes of these functions should be fixed. Moreover, > I think psa_outvec *out_vecs should drop the const qualifier to match > psa_call(...) prototypes, as it's an output parameter and needs to be non-const. > I have raised https://developer.trustedfirmware.org/T313 to keep track of this. > > Thanks, > Antonio > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of DeMars, > Alan via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 10 April 2019 22:12 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? > > It seems to me that the 'psa_invec' type is incorrectly being used where the > 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. > > > > In tfm_api.h, I think this: > > > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_invec *out_vecs); > > > > should be this: > > > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_outvec *out_vecs); > > > > > > And, in the implementation of the tfm_psa_call_veneer > > within tfm_psa_api_client.c, I think this: > > > > __tfm_secure_gateway_attributes__ > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_invec *out_vecs) > > > > should be this: > > > > __tfm_secure_gateway_attributes__ > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_outvec *out_vecs) > > > > > > And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: > > > > psa_invec in_vecs, out_vecs; > > > > should be this: > > > > psa_invec in_vecs; > > psa_outvec out_vecs; > > > > > > Alan > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 9 months

1
0
0 0

Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

by Antonio De Angelis

Hi Alan, I think you're right, the prototypes of these functions should be fixed. Moreover, I think psa_outvec *out_vecs should drop the const qualifier to match psa_call(...) prototypes, as it's an output parameter and needs to be non-const. I have raised https://developer.trustedfirmware.org/T313 to keep track of this. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 April 2019 22:12 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. In tfm_api.h, I think this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs); should be this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs); And, in the implementation of the tfm_psa_call_veneer within tfm_psa_api_client.c, I think this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs) should be this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs) And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: psa_invec in_vecs, out_vecs; should be this: psa_invec in_vecs; psa_outvec out_vecs; Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 9 months

1
0
0 0

psa_invec type mismatch in tfm_psa_call_veneer?

by DeMars, Alan

It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. In tfm_api.h, I think this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs); should be this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs); And, in the implementation of the tfm_psa_call_veneer within tfm_psa_api_client.c, I think this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs) should be this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs) And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: psa_invec in_vecs, out_vecs; should be this: psa_invec in_vecs; psa_outvec out_vecs; Alan

5 years, 9 months

1
0
0 0

Platform: Create platform service for pin functions

by Michel JAOUEN

Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards

5 years, 9 months

1
0
0 0

[RFC] Core: Set PendSV priority to lowest

by Ken Liu (Arm Technology China)

Hi, I have created a patch to set PenSV priority as lowest, which makes more sense that other high priority interrupts may preempt scheduling and affect the scheduling result. The issue is created here and you can find gerrit link in comment: https://developer.trustedfirmware.org/T310 Please publish your comments under this issue if you have. Thanks -Ken

5 years, 9 months

1
0
0 0

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

by Michel JAOUEN

For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations.

5 years, 9 months

1
0
0 0

Support SST_FLASH_PROGRAM_UNIT=8

by Michel JAOUEN

Hello, For this support , I created https://developer.trustedfirmware.org/T305 Best regards

5 years, 9 months

1
0
0 0

Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3

by Gyorgy Szing

Hi Michel, Apologies, somehow my response yesterday got lost, so here it goes again: I re-read the documentation and the way you use this macro seems to be valid when targeting v8-M based chips. I see two solutions for your problem: 1. I created a ticket to remove the --mcmse compile flag for non-secure projects. See: https://developer.trustedfirmware.org/T304 After this is fixed, your current code will work as expected. 2. Currently TF-M uses the __DOMAIN_NS macro to define the target domain for the source-code. It is an option to change your code to use this macro. I suggest going for this option if your code is not v8-M specific, and may need to support other architectures in the future. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 03 April 2019 17:40 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hi Michel, A ticket has been raised by Gyorgy to track this: https://developer.trustedfirmware.org/T304 Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 03 April 2019 03:03 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] build of NSPE with flag __ARM_FEATURE_CMSE=3 Hello, The flag is defined to __ARM_FEATURE_CMSE == 3U. In documentation, I can read : __ARM_FEATURE_CMSE == 3U when Toolchain targets the secure state of CMSE (implies the availability of the TT instruction). My soc files relies on this flag to select by default a secure peripheral register address or a non secure peripheral address. With the non secure compiled with __ARM_FEATURE_CMSE == 3U , by default secure peripheral address are selected. Is it a correct usage to build NSPE with __ARM_FEATURE_CMSE == 3U ? Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 9 months

1
0
0 0

Re: [TF-M] build with GNUARM with option -Os

by Edison Ai (Arm Technology China)

Hi Michel, We will pick up this and try to push a patch to fix it soon. Hi Alan, Thanks for your workaround, and it is very helpful. We will update the T234 as soon as possible after the patch ready. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, April 3, 2019 9:32 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] build with GNUARM with option -Os I assumed there was an outstanding pull request for this ticket: https://developer.trustedfirmware.org/T234 Alan -----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, April 02, 2019 6:59 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] build with GNUARM with option -Os Hi Alan, Is it OK for you to commit this change? -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > DeMars, Alan via TF-M > Sent: Wednesday, April 3, 2019 5:50 AM > To: Michel JAOUEN <michel.jaouen(a)st.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] build with GNUARM with option -Os > > I had a similar problem. Upon advice in this email list, I fixed it by > changing the implementation of "tfm_core_ns_ipc_request()" in > secure_fw/core/tfm_psa_api_client.c. > > Add 'volatile' to the declaration of these variables: > > struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > change to: > > volatile struct tfm_sfn_req_s desc, *desc_ptr = &desc; > > After this change, I am able to build and run with -O3 as well as -Os. > > I don't know why this fix hasn't been added to the master branch as > this problem has already been identified. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf > Of Michel JAOUEN via TF-M > Sent: Tuesday, April 02, 2019 4:11 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] [TF-M] build with GNUARM with option -Os > > Hello, > I tested my board port on top of > 1c266ae74bd93c2ef290e9aac0caecf92b06b93d > Without option -Os , the tests with ConfigCoreIPC.cmake are passed . > When I put the option -Os , 1st test is failing in Hardware Fault. > > For info, the test with ConfigRegression.cmake and option -Os is passed . > > With the configuration -Os , code footprint is much better. > > Is it plan to activate this option in master ? Is the same issue > reproduced on another board ? > > Best regards > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M