- TF-M - lists.trustedfirmware.org

by Stanislav Jancik

Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav

6 years

1
0
0 0

FW: Trusted boot - rollback protection

by Tamas Ban

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) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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

1
0
0 0

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

by Miklos Balint

Michel, I agree there is a need for a more generic design pattern for such platform-specific features. I think that there should be a single entry point for any platform specific service request to the platform/ directory and each platform should/could list the specific features it supports. Then the specific function type would be encoded in an invec to the service request. But I think a more detailed design proposal is needed with enough room for discussion before committing to a new pattern, and I'd prefer to avoid introducing platform dependencies in the services/ folder. That folder should ideally just have an indirection across HAL to a platform-specific service request arbiter. Any opinions or should I produce a more detailed proposal to show what I mean? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 11 April 2019 13:57 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Platform: Create platform service for pin functions 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years

2
1
0 0

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

6 years

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

6 years

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

6 years

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

6 years

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

6 years

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

6 years

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.

6 years

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

6 years

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

6 years

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

6 years

1
0
0 0

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

by Antonio De Angelis

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

6 years

1
0
0 0

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

by DeMars, Alan

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

6 years

1
0
0 0

build of NSPE with flag __ARM_FEATURE_CMSE=3

by Michel JAOUEN

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

6 years

1
0
0 0

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

by Ken Liu (Arm Technology China)

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

6 years

1
0
0 0

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

by DeMars, Alan

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

6 years

1
0
0 0

build with GNUARM with option -Os

by Michel JAOUEN

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

6 years

1
0
0 0

Re: [TF-M] PSA Test Suite forum?

by Andrej Butok

Hi Antonio, Ok, so the TFM is using the old API. Hope, it will be updated soon. I prefer do not downgrade the test suite from master, as it contains >50 of new commits. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, April 1, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] PSA Test Suite forum? Hi Andrej, I have replied on the GitHub issue as well, copy-pasting my reply below: TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M Sent: 01 April 2019 09:14 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite forum? Andrej, Yes, the PSA test suite was developed by different team. If it is a common topic, you can report the issue at any of the site, then we will sync it internal. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Monday, April 1, 2019 3:59 PM To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Hi Qixiang Xu, I have added https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team? Thanks, Andrej -----Original Message----- From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Sent: Monday, April 1, 2019 9:41 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Andrej, You can report any issue or concern at: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. 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
1
0 0

Re: [TF-M] PSA Test Suite forum?

by Antonio De Angelis

Hi Andrej, I have replied on the GitHub issue as well, copy-pasting my reply below: TF-M uses a version of the API which is marked 0.1.0b. The psa-arch-tests, on the master branch, have moved to use a newer version of the API, while on the branch marked ew_beta0 they use the version of the API compatible with the one TF-M uses, hence TF-M PSA API compliance needs to be tests using the ew_beta0 branch. Work is ongoing on TF-M side to move to newer versions of the API. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu (Arm Technology China) via TF-M Sent: 01 April 2019 09:14 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite forum? Andrej, Yes, the PSA test suite was developed by different team. If it is a common topic, you can report the issue at any of the site, then we will sync it internal. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Monday, April 1, 2019 3:59 PM To: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Hi Qixiang Xu, I have added https://github.com/ARM-software/psa-arch-tests/issues/79 Not sure, what forum to use if it is a common topic related to both TFM and Test-suite. Is the PSA test suite developed by other independent team? Thanks, Andrej -----Original Message----- From: Qixiang Xu (Arm Technology China) <Qixiang.Xu(a)arm.com> Sent: Monday, April 1, 2019 9:41 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: RE: PSA Test Suite forum? Andrej, You can report any issue or concern at: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. 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

1
0
0 0

Re: [TF-M] PSA Test Suite forum?

by Qixiang Xu (Arm Technology China)

Andrej, You can report any issue or concern at: https://github.com/ARM-software/psa-arch-tests/issues Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, April 1, 2019 3:29 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite forum? Hello, Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )? Or we may use this one? Thanks Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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
2
0 0

PSA Test Suite forum?

by Andrej Butok

Hello, Do you have a forum dedicated to the PSA Test-suite (https://github.com/ARM-software/psa-arch-tests )? Or we may use this one? Thanks Andrej

6 years

1
0
0 0

[twin-cpu]Dual core communication design document for review

by David Hu (Arm Technology China)

Hi all, I've posted a design document for dual core communication in twin cpu project. Could you please review it at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/communication_… Any comment is welcome. Thank you. Best regards, Hu Ziji

6 years

2
4
0 0

[RFC] Isolation level 2 patches

by Ken Liu (Arm Technology China)

Hi, The isolation level 2 patches are pushed for reviewing; you can find all of them under the issue: https://developer.trustedfirmware.org/T294 The design document was put at: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The first group of patches are working on AN521 with ARMCLANG build. Rest options supporting would come later. With higher isolation level, some functions may not work such as CLIB (malloc/free e.g.). These features need to be supported after dedicated implementation is done. You can check the [RFC] discussion sent in mailing list of the isolation level 2 for details. Isolation level 2 use dedicated config file: "ConfigCoreIPCTfmLevel2.cmake" so the IPC on isolation level 1 is not affected by this change. Please help to comment in documents and patches - current the document has no comment area so you can put comments under the issue link, or just reply in mailing list. Creating issues is another valid options ; ) Thanks! -Ken

6 years

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: Please explain tfm_register_client_id() use case

by DeMars, Alan

Yes, that idea would resolve the problem. I’m not sure I understand the use case for multiple updates to a context’s client Id. What is the thought behind that? Alan > On Mar 28, 2019, at 2:23 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Alan, > > You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. > > The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. > > I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. > This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. > > Is this an acceptable amendment? > > Regards > Miklos > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 26 March 2019 00:00 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Please explain tfm_register_client_id() use case > > As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. > > It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. > > However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. > > What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). > > Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. > > 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

6 years, 1 month

2
1
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Hu (Arm Technology China)

Hi Chris, Sorry for the delayed reply. Please check my comments in below. Just about small details. Please correct me if I misunderstand anything. 1. In my own opinion, it can be possible to use IPC to synchronize mailbox services between two cores, during initialization. The synchronization is only trigged when the mailbox mechanism is ready on mailbox server or client. It means that the IPC module should be also configured. Based on the above assumption, using IPC to synchronize the two cores is more generic and convenient than accessing shared memory. If using shared memory to pass status flag, it can be necessary to adjust the address of the shared memory occasionally according to the memory assignment in different applications. 2. I'd like to suggest that we shall discuss more about when the booting HAL APIs are invoked in TF-M. `tfm_core_init()` initializes the TF-M core. Thus in theory, `tfm_core_init()` is irrelevant to the system topology or platform implementations. As a result, IMO, it can be more reasonable to put the HAL APIs outside the `tfm_core_init()`. 3. ` tfm_spm_hal_wait_for_ns_cpu_ready()` can be optional. The secure core acts as a server and it is driven by the request from NS core. The secure core actually doesn't have to wait for an explicit signal to know NS is ready. The synchronization can be guaranteed if NS core starts request via mailbox only after secure core is available. 4. It can be unnecessary to require calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main()`. It might be too early to wait in `main()` and may block other initializations which don't rely on mailbox. This API can be invoked in mailbox functionalities. The whole NS initialization can continue, including enabling application threads, until a NS application requests Secure services via mailbox at the very first time. Thus the whole dual core design can be more generic since the mailbox workflow should be identical on diverse platforms. And we can save the time and effort to hack each RTOS initialization. In other words, I wonder if we can make calling `tfm_spm_hal_wait_for_s_cpu_ready()` in NS `main() as an option and allow other implementations. Thank you. Best regards, Hu Ziji -------------------------------------------------------------------------------------------------------------- Date: Thu, 14 Mar 2019 18:50:56 +0000 From: Christopher Brand <chris.brand(a)cypress.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] [RFC] twin cpu bootloader design document Message-ID: <BYAPR06MB5301EBF02F4C0B60A9BB7742FE4B0(a)BYAPR06MB5301.namprd06.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris

6 years, 1 month

3
7
0 0

proposed change in Musca B1

by Tamas Kaman

Hi All, I'd like to notify everyone about a proposed change in Musca B1 platform in TF-M. Everyone who is using that platform might be affected. The code on Musca B1 is currently running from the external QSPI flash. With the coming change this moves to a much faster internal embedded Flash, so all you might observe is faster code execution. Link to review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/669/ Also, for loading the image to the a board another version of DAPLink FW will be needed. The eFlash type DAPLink FW can be downloaded from Arm Community page: https://community.arm.com/developer/tools-software/oss-platforms/w/docs/425… A short description of how to update the DAPLink FW can be found here as well. Thanks, Tamas 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, 1 month

1
0
0 0

Re: [TF-M] Please explain tfm_register_client_id() use case

by Miklos Balint

Alan, You are absolutely right that registering client ID should normally be done once, preferably right after AllocModule. The current design allows multiple updates to be made, and for this to be possible, we identify the one to be updated by it being the active one. I do see an opportunity to extend this so that the last NS context to be Allocated can also be assumed to be the target of a registration in lieu of the active context if there isn't one. This way we keep the option to update ID when a context is active while also allow an easy and low overhead registration for the context that's latest to have been Allocated. Is this an acceptable amendment? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 26 March 2019 00:00 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please explain tfm_register_client_id() use case As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] SYSTICK ownership

by Ken Liu (Arm Technology China)

Hi Alan, Sorry for the late response - the secure IRQ patches are on the way but currently we don't have scenarios for this case. We would create a ticket for tracking this question and let's collect comment there. And, this topic sounds like a timer requirement, so can you tell the actual user scenario? For example, would there still be requirements of using SYSTICK in secure partition if some timer things is available? Thanks. -Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of DeMars, Alan via TF-M Sent: 19 February 2019 02:47 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.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] SYSTICK ownership My concern was the value one would provide for the "line_num" field within the manifest. The SYSTICK uses vector 15 which I believe would correspond to "line_num" = -1. I'm not sure the design accommodates negative line_nums. Also, disabling the SYSTICK interrupt while servicing its interrupt can't be handled in the normal way user IRQs are disabled. Special case code would be required in the SPM to support the SYSTICK as a secure partition interrupt. 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: Monday, February 18, 2019 5:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] SYSTICK ownership Hi Alan, >From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of > DeMars, Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure > SYSTICK timer and its interrupt? > If so, how is it specified in the SP manifest? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Andrej Butok

Hi Mate, OK. It's good to know that this is the known issue. I will wait for a final review and merge. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Wednesday, March 27, 2019 2:45 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TFM Core regression tests Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- 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, 1 month

1
0
0 0

Re: [TF-M] TFM Core regression tests

by Mate Toth-Pal

Hi Andrej, Yes, on the master branch this is a limitation. I already have a few patches on review to fix this: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/693/10 https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/683/11 They are most probably going to be merged with the secure IRQ handling commits. You can also cherry pick those for yourself for testing purposes, there should be no conflict, as it is quite independent from the parent commits on review. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 27 March 2019 14:32 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM Core regression tests Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

TFM Core regression tests

by Andrej Butok

Hello We are trying to enable & compile TFM Core tests. But it looks like they are only for MPS2 platform: 1) tfm_ss_core_test.c: .... #include "smm_mps2.h" ... static psa_status_t test_peripheral_access(void) { struct arm_mps2_fpgaio_t *fpgaio = SEC_MPS2_FPGAIO; ... etc. 2) tfm_partition_list.inc ... #ifdef TFM_PARTITION_TEST_CORE ... PARTITION_ADD_PERIPHERAL(TFM_SP_CORE_TEST, TFM_PERIPHERAL_FPGA_IO); #endif /* TFM_PARTITION_TEST_CORE */ ... What do you suggest ? What is the plan? Should we to skip/ignore the TFM Core regression tests now? Thanks Andrej Butok SW Tech Lead Security & Connectivity, Microcontrollers NXP Semiconductors

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Andrej Butok

Thank you, Antonio Looking forward for the 100% Crypto Service usage, it will solve the mbedTLS duplication issue. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, March 26, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, Regarding the below: > Why the TFM services (SST, attestation) do not call PSA Crypto API? Attestation already calls the PSA Crypto APIs, and we are working actively on implementing the crypto bindings for SST to call the corresponding PSA Crypto API's. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 26 March 2019 08:18 To: tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%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… -- 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… -- 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, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Antonio De Angelis

Hi, Regarding the below: > Why the TFM services (SST, attestation) do not call PSA Crypto API? Attestation already calls the PSA Crypto APIs, and we are working actively on implementing the crypto bindings for SST to call the corresponding PSA Crypto API's. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 26 March 2019 08:18 To: tf-m(a)lists.trustedfirmware.org; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%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… -- 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://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

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by David Wang (Arm Technology China)

Hi Andrej, Yes, I agree this is a useful design to mitigate the code size issue. Just sharing the advice from security perspective. Basically, we need to review the shared libs carefully(one of the focus of threat modelling). It's not a mandatory limit. From PSA FF spec v1.0 beta1 section 3.1.4 (Mandatory isolation rules) and 3.1.5 (Optional isolation rules), it's OK to have the shared RO code sections. It doesn't break the mandatory isolation rule I3 - If domain A needs protection from domain B, then Private data in domain A cannot be accessed by domain B. But it's worth to notice/mention that this will break optional isolation rules I4 and I5. I4 - If domain A needs protection from domain B, then Code and Constant data in domain A is not readable or executable by domain B. I5 - Code in a domain is not executable by any other domain. It makes sense to give the choice to the users. (may notify the user about the potential security risk) > Why the TFM services (SST, attestation) do not call PSA Crypto API? I think the experts of the modules might be more suitable than me to answer this question. 😊 Thanks. Hi @Ken Liu (Arm Technology China), I got your reply in another thread, so just to gather them here. >For first point, we can take a security analysis on this part and check if there are vulnerabilities. >The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. Yes, like I mentioned above it's one of the focus of threat modelling. >For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. Understand. Just thinking if we can keep the shared libs in the same protection domain. (to avoid breaking optional isolation rules) BTW, from PSA FF spec v1.0 beta1 section 3.1.2(memory access rules) rule l1, we may need to consider the separation of RO-Code and RO-data(execution never). Thanks. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Monday, March 25, 2019 7:04 PM To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%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… -- 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://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hi, For first point, we can take a security analysis on this part and check if there are vulnerabilities. The security requirement for these code are quite high, you can take 'memset' as example, it is read-only, caller stack based so no footprint would leave to another caller. For seconds point, it is do-able -- but need big change everywhere; and it back to the per-partition library design while we move to isolation level 3. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Wang (Arm Technology China) via TF-M > Sent: Monday, March 25, 2019 5:57 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi Ken, > Some comments from security review's perspective. > * Using shared libraries may give the window to exploit the vulnerabilities. App > RoT can analyze the shared lib to find out the useable vulnerabilities for > attacking PSA RoT. > * Is it a good idea to have two separate shared libs - one for all app RoT and one > for all PSA RoT for isolation level2? (can still share one copy for level1.) > > Regards, > David Wang > Arm Electronic Technology (Shanghai) Co., Ltd > Phone: +86-21-6154 9142 (ext. 59142) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Monday, March 25, 2019 5:05 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > > The document is updated due to a change in MPU regions part: > > In original design, some partition libraries like 'thread_exit' is going to be linked > with partition statically, which means there would be multiple copies of these > libraries for each partition. This provided strict protection of isolation but it > looks over-protect. > > If we keep one shared code region for each partition to call these libraries, we > could: > * Save memory > * The protection is enough if we mark the code area as read-only. > > In this case, the unprivileged code and RO region needs to be kept and these > shared codes could be put there. > The requirement of these codes are: > * These codes must be thread safe and reentrant > * These codes must be put in read-only region > > The change mainly happen under section "Linker script sections re-arrangement". > Please help to comment. > > Thanks! > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Thursday, March 21, 2019 3:20 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > > > Hi, > > The document is updated, and keep open for comments ; ) > > > > The updated content is: > > > > 1. Available MPU regions for peripheral has number limitation based > > on platform. If a SP needs many un-continuous peripheral registers and > > the number exceeds available MPU number, it needs further investigation. > > 2. Rely on linker to clean the unused object files instead of > > remove them in scatter before the dependency is fully figured out. > > > > Thanks! > > > > -Ken > > > > From: Ken Liu (Arm Technology China) > > Sent: Tuesday, February 19, 2019 6:44 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [RFC] Design document of isolation level 2 on TF-M > > > > Hello, > > The first IPC implementation works under isolation level 1. The high > > isolation levels need to be there to get compatible with PSA Firmware > > Framework. A design document is created about implementing isolation level 2 > for IPC model: > > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > > m_isolation_level_2/ > > > > The mainly change of isolation level 2 compare to isolation level 1 is: > > * Put AppRoT Secure Partitions' components with same attribute (code, > > read- only data, read-write data) into the same region, which helps > > MPU setting region attributes. > > * Change Secure Partition privileged setting based on Secure Partition > > type while scheduling. > > * Change mechanism of privileged API, such as printf. > > > > If you have any comments please share it. You can reply in mailing > > list if there is no place for putting comments on the page. > > > > Thank you! > > > > -Ken > > > > -- > > 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

6 years, 1 month

1
0
0 0

Please explain tfm_register_client_id() use case

by DeMars, Alan

As currently specified, I don't see a simple way to invoke the tfm_register_client_id() API ONLY ONCE for each NS client thread. It appears that tfm_register_client_id() must be called after TZ_LoadContext_S() because the clientId provided by tfm_register_client_id() is always associated with the CURRENT NS MemoryId. However, TZ_LoadContext_S() is designed to be called only when the NS OS actually switches to a new NS thread. This creates pressure for tfm_register_client_id() to be called during a NS thread switch. However, calling tfm_register_client_id() on EVERY NS context switch is redundant and CPU wasteful. Adding code to test whether tfm_register_client_id() has already been called for a particular NS thread also seems wasteful. What seems natural to me is to add a MemoryId argument to tfm_register_client_id() so that the clientID can be mapped to the MemoryId provided by TZ_AllocModuleContext_S() right after TZ_AllocModuleContext_S() is called (ie only once). Please correct my understanding of how tfm_register_client_id() is intended to be used if the above analysis is off base. Alan

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Andrej Butok

Hi David, > Using shared libraries may give the window to exploit the vulnerabilities. Yes, you are right. BUT Code size may be a very critical parameter especially for constrained MCUs. Please do not give any mandatory limits. If any, they should be configurable. Let's give a possibility to choose for final users. BTW: 1) Current TF-M is using library approach with mbedTLS copy per each service. OK, security => but wasting of resources. In our code, we are using one copy of mbedTLS to avoid this type of wasting, but it requires original code modification. Please, give more freedom to final TFM users! 2) Why the TFM services (SST, attestation) do not call PSA Crypto API? It will eliminates mbedTLS duplication. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 10:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > loper.trustedfirmware.org%2Fw%2Ftf_m%2Fdesign%2Ftrusted_firmware-& > data=02%7C01%7Candrey.butok%40nxp.com%7C6a9c2cb6a5034aec48b908d6b10845 > 48%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406628979&amp > ;sdata=yPus0lkd4L71ng5Z5o2hu2bDEMBAzSwUxAm1fyYf564%3D&reserved=0 > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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%7C6a9c2cb6a5034aec48b908d6b1084548%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636891046406638984&sdata=7Wva1R6Lv > EKMxCpaVr6gRE26Fodub%2FPTQlLOiB2YvX0%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… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by David Wang (Arm Technology China)

Hi Ken, Some comments from security review's perspective. * Using shared libraries may give the window to exploit the vulnerabilities. App RoT can analyze the shared lib to find out the useable vulnerabilities for attacking PSA RoT. * Is it a good idea to have two separate shared libs - one for all app RoT and one for all PSA RoT for isolation level2? (can still share one copy for level1.) Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, March 25, 2019 5:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based > on platform. If a SP needs many un-continuous peripheral registers and > the number exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of > remove them in scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high > isolation levels need to be there to get compatible with PSA Firmware > Framework. A design document is created about implementing isolation level 2 for IPC model: > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, > read- only data, read-write data) into the same region, which helps > MPU setting region attributes. > * Change Secure Partition privileged setting based on Secure Partition > type while scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing > list if there is no place for putting comments on the page. > > Thank you! > > -Ken > > -- > 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

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hi, The document is updated due to a change in MPU regions part: In original design, some partition libraries like 'thread_exit' is going to be linked with partition statically, which means there would be multiple copies of these libraries for each partition. This provided strict protection of isolation but it looks over-protect. If we keep one shared code region for each partition to call these libraries, we could: * Save memory * The protection is enough if we mark the code area as read-only. In this case, the unprivileged code and RO region needs to be kept and these shared codes could be put there. The requirement of these codes are: * These codes must be thread safe and reentrant * These codes must be put in read-only region The change mainly happen under section "Linker script sections re-arrangement". Please help to comment. Thanks! -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Thursday, March 21, 2019 3:20 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Design document of isolation level 2 on TF-M > > Hi, > The document is updated, and keep open for comments ; ) > > The updated content is: > > 1. Available MPU regions for peripheral has number limitation based on > platform. If a SP needs many un-continuous peripheral registers and the number > exceeds available MPU number, it needs further investigation. > 2. Rely on linker to clean the unused object files instead of remove them in > scatter before the dependency is fully figured out. > > Thanks! > > -Ken > > From: Ken Liu (Arm Technology China) > Sent: Tuesday, February 19, 2019 6:44 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [RFC] Design document of isolation level 2 on TF-M > > Hello, > The first IPC implementation works under isolation level 1. The high isolation > levels need to be there to get compatible with PSA Firmware Framework. A > design document is created about implementing isolation level 2 for IPC model: > https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware- > m_isolation_level_2/ > > The mainly change of isolation level 2 compare to isolation level 1 is: > * Put AppRoT Secure Partitions' components with same attribute (code, read- > only data, read-write data) into the same region, which helps MPU setting > region attributes. > * Change Secure Partition privileged setting based on Secure Partition type while > scheduling. > * Change mechanism of privileged API, such as printf. > > If you have any comments please share it. You can reply in mailing list if there is > no place for putting comments on the page. > > Thank you! > > -Ken > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] English topics

by Summer Qin (Arm Technology China)

Really sorry! sent by mistake. On 3/21/19, 5:41 PM, "TF-M on behalf of Summer Qin (Arm Technology China) via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: 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, 1 month

1
0
0 0

English topics

by Summer Qin (Arm Technology China)

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, 1 month

1
0
0 0

[RFC] Design document of SST IPC model

by Summer Qin (Arm Technology China)

Hi, The design document of SST IPC compatibility has been updated due to SST supports Protected Storage API now. Please take a look at the document and give feedback if you have: https://developer.trustedfirmware.org/w/tf_m/design/sst_ipc_compatibility/ Thanks a lot! Summer

6 years, 1 month

1
0
0 0

File attribute and line ending in sources

by Edison Ai (Arm Technology China)

Hi， I created two patches to fix the line ending and file attribute problem in the source code. Could you take a look that these patches and mind the file attribute and line ending change while submitting patches? Patches links are here: * https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/723/ * https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/724/ Thanks, Edison

6 years, 1 month

1
0
0 0

[RFC] Design document of isolation level 2 on TF-M

by Ken Liu (Arm Technology China)

Hello, The first IPC implementation works under isolation level 1. The high isolation levels need to be there to get compatible with PSA Firmware Framework. A design document is created about implementing isolation level 2 for IPC model: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… The mainly change of isolation level 2 compare to isolation level 1 is: * Put AppRoT Secure Partitions' components with same attribute (code, read-only data, read-write data) into the same region, which helps MPU setting region attributes. * Change Secure Partition privileged setting based on Secure Partition type while scheduling. * Change mechanism of privileged API, such as printf. If you have any comments please share it. You can reply in mailing list if there is no place for putting comments on the page. Thank you! -Ken

6 years, 1 month

1
1
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, For you question, please see my comments: If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? - Yes. Should the SST/Crypto/Attestation services be disabled when IPC is enabled? - No, we do not have to disable them. May the Library and IPC APIs be used simultaneously? - Yes. When using " ConfigCoreIPC.cmake" configure file with enabling the " REGRESSION", you can see all the regression test can work. What part of TFM is using IPC? - There are two IPC test partitions to use the IPC: trusted-firmware-m/test/test_services/tfm_ipc_client and trusted-firmware-m/test/test_services/tfm_ipc_service. They are used to do basic IPC function tests. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, March 20, 2019 3:36 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? Should the SST/Crypto/Attestation services be disabled when IPC is enabled? May the Library and IPC APIs be used simultaneously? What part of TFM is using IPC? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, March 20, 2019 8:22 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- 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… -- 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… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] IPC and clang

by Andrej Butok

Hi Edison, If I understand well, the Crypto, SST and Attestation services do not use IPC, so far. Right? Should the SST/Crypto/Attestation services be disabled when IPC is enabled? May the Library and IPC APIs be used simultaneously? What part of TFM is using IPC? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, March 20, 2019 8:22 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- 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… -- 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, 1 month

1
0
0 0

Feature 'Custom code generating scripts with Jinja2' has been merged

by Ken Liu (Arm Technology China)

Hi, The patch for applying Jinja2 to generate custom code has been merged into branch 'master'. With these two patches, scatter loader template are also supported. IMPORTANT: Please install Jinja2 before using this feature. You can check ' docs/user_guides/tfm_sw_requirement.md' for installation. Thanks. -Ken > -----Original Message----- > From: Ken Liu (Arm Technology China) > Sent: Tuesday, March 19, 2019 7:09 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: Replace custom code generating scripts with Jinja2 > > Hi, > I saw there is no concern raised about applying Jinja2 into TF-M project, and > some code review is done on these patches. > Plan to merge it at end of Mar 19th, if you have something please just shout 😉 > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > Thanks > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Wednesday, January 23, 2019 2:18 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [Tf-m] Replace custom code generating scripts with Jinja2 > > > > Hi Mate, > > I have checked your change and the document, it looks quite easy to > > support conditional including. > > I am OK for this tool. > > > > Thanks. > > > > -Ken > > > > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > > Sent: Monday, January 21, 2019 9:35 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: Replace custom code generating scripts with Jinja2 > > > > > > Hi Mate, > > > > Thanks for the proposal. It looks nice. > > > > I have read the "Improvements over the current solution" part and I > > think the "More advanced functionality" is the point I am interested > > in. There are some necessary jobs to be done in the code generating > > scripts for IPC; hope using this tool could help on that. One thing we are > investigating is: > > > > * We need to put PSA RoT and APP RoT into different groups in linker script; > > current tool just put all partitions together and ignores partition type. > > > > > > > > Can you help to check if the new tool could make this change easier? > > > > > > > > Thanks. > > > > > > -Ken > > > > ________________________________ > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > > bounces(a)lists.trustedfirmware.org>> on behalf of Mate Toth-Pal via > > TF-M <tf- > > m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> > > Sent: Monday, January 21, 2019 8:37:58 PM > > To: > > tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Cc: nd > > Subject: [Tf-m] Replace custom code generating scripts with Jinja2 > > > > Hi All, > > > > Based on the design proposal published here: > > https://developer.trustedfirmware.org/w/tf_m/design/code_generation_wi > > th_j inja2/ I am planning to replace the code generation tool > > currently used in the TF- M with the Jinja2 template engine. > > > > I already prepared the change that implements this. It is available > > for review and testing in this gerrit review: > > https://review.trustedfirmware.org/#/c/trusted- > > firmware-m/+/507/ > > > > Please note, that this introduces a new tool dependency: jinja2 v2.10 > > python library have to be installed to generate code from the > > partition manifests. Earlier than 2.10 versions won't work, as one of > > the templates relies on the namespace feature introduced in this version. > > > > Based on this change I also would like to make the secure sct files > > automatically generated (just like the secure ld files). The gerrit review for this > change is here: > > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > > > Should you have any questions, suggestions, objections, please do not > > hesitate to contact! > > > > Thanks, > > Mate > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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

6 years, 1 month

1
0
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, We tested the IPC works on Musca A but not try it on Musca B yet. The current IPC related patches are used to enable IPC mechanism, but services such as crypto, protect storage and attestation are yet to make use of IPC. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 6:06 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC and clang Hi Edison, OK. So, according to https://review.trustedfirmware.org/c/trusted-firmware-m/+/463/ the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- 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… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Re: [TF-M] Replace custom code generating scripts with Jinja2

by Ken Liu (Arm Technology China)

Hi, I saw there is no concern raised about applying Jinja2 into TF-M project, and some code review is done on these patches. Plan to merge it at end of Mar 19th, if you have something please just shout 😉 https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Wednesday, January 23, 2019 2:18 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [Tf-m] Replace custom code generating scripts with Jinja2 > > Hi Mate, > I have checked your change and the document, it looks quite easy to support > conditional including. > I am OK for this tool. > > Thanks. > > -Ken > > From: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Sent: Monday, January 21, 2019 9:35 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: Replace custom code generating scripts with Jinja2 > > > Hi Mate, > > Thanks for the proposal. It looks nice. > > I have read the "Improvements over the current solution" part and I think the > "More advanced functionality" is the point I am interested in. There are some > necessary jobs to be done in the code generating scripts for IPC; hope using this > tool could help on that. One thing we are investigating is: > > * We need to put PSA RoT and APP RoT into different groups in linker script; > current tool just put all partitions together and ignores partition type. > > > > Can you help to check if the new tool could make this change easier? > > > > Thanks. > > > -Ken > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> on behalf of Mate Toth-Pal via TF-M <tf- > m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> > Sent: Monday, January 21, 2019 8:37:58 PM > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > Cc: nd > Subject: [Tf-m] Replace custom code generating scripts with Jinja2 > > Hi All, > > Based on the design proposal published here: > https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_j > inja2/ I am planning to replace the code generation tool currently used in the TF- > M with the Jinja2 template engine. > > I already prepared the change that implements this. It is available for review and > testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted- > firmware-m/+/507/ > > Please note, that this introduces a new tool dependency: jinja2 v2.10 python > library have to be installed to generate code from the partition manifests. Earlier > than 2.10 versions won't work, as one of the templates relies on the namespace > feature introduced in this version. > > Based on this change I also would like to make the secure sct files automatically > generated (just like the secure ld files). The gerrit review for this change is here: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ > > Should you have any questions, suggestions, objections, please do not hesitate > to contact! > > Thanks, > Mate > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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

6 years, 1 month

1
0
0 0

Re: [TF-M] IPC and clang

by Andrej Butok

Hi Edison, OK. So, according to https://review.trustedfirmware.org/c/trusted-firmware-m/+/463/ the armclang IPC was added only to one platform (target/mps2/an521/armclang/mps2_an521_s.sct). What about Musca A and Musca B? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:52 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You can see the log history of master branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…p;reserved=0. All the IPC patches had been existed in master branch. You can use the master branch now, all the IPC functions had been ready for GCC and ARMCLANG. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Edison, https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust… master head the latest commit is still 4-day old (4 days Core: Retrieve extra parameter from correct positionHEADmaster Summer Qin). Should I wait some time till it will be propagated to the public git? Thanks, Andrej -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Tuesday, March 19, 2019 9:26 AM To: Andrej Butok <andrey.butok(a)nxp.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Hi Andrej, You are welcome. Now, the "feature-ipc" branch had been merge into the master branch with the merge patch mentioned below. So all the patches in "feature-ipc" branch had been merge into master too. You can find the related IPC patch in the log history of master branch. The IPC can works rightly in GCC and ARMCLANG on master branch. Thanks, Edison -----Original Message----- From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, March 19, 2019 4:10 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: IPC and clang Thanks Adison, Yes, we are using the master branch. When are you planning to merge the mentioned fix to the mainline? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Tuesday, March 19, 2019 9:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] IPC and clang Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…p;reserved=0. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- 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, 1 month

1
0
0 0

Re: [TF-M] IPC and clang

by Edison Ai (Arm Technology China)

Hi Andrej, I think you mention the "Merge remote-tracking branch 'feature-ipc' into 'master" patch: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/677/-1..2. This is a merge patch to fix the merge conflicts. The original patch to support to change the linker file is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/463/. You can see both the linker files for GCC and ARMCLANG are changed. IPC had been developed and tested on both the GCC and ARMLANG already. Thanks for your question. Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, March 19, 2019 3:35 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] IPC and clang Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

IPC and clang

by Andrej Butok

Hello, I have noticed, that with adding the IPC feature to master branch, it were updated GCC linker files (#ifdef TFM_PSA_API sections), but ARMCLANG linker files are without any change. Does it mean that IPC was developed and tested only using GCC? Is there a plan to updated the armclang linker files? Thanks, Andrej Butok

6 years, 1 month

1
0
0 0

[RFC] IPC scheduler on AN519

by Ken Liu (Arm Technology China)

Hi, A patch is submitted to support IPC scheduler on AN519; which makes IPC work for baseline: https://review.trustedfirmware.org/c/trusted-firmware-m/+/715 Please help to take a review on it. Thanks ; ) -Ken

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] twin cpu bootloader design document

by David Brown

On Thu, Mar 14, 2019 at 06:51:04PM +0000, Christopher Brand via TF-M wrote: >I've posted a design document for bootloader changes to support twin >cpu at >https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ There are efforts underway to get the TF-M changes to the bootloader contributed back to the upstream MCUboot project. We should be trying to make sure that we continue this effort, as well as to make sure that any efforts to extend the bootloader are done upstream, and not in the TF-M-specific branch. Are you expecting to be running the non-secure CPU before the secure CPU has finished verifying the images? David

6 years, 1 month

2
3
0 0

Fix for issue T276 has been merged

by Ken Liu (Arm Technology China)

Hi, Fix for the issue 'stacking issue in psa_call when FP was enabled' has been merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/713/ And the issue: https://developer.trustedfirmware.org/T276 This commit fixes the problem while hardware FP is enabled, 5th parameter fetching problem for psa_call(). Please check the latest master branch to get the fix. Thanks. -Ken

6 years, 1 month

1
0
0 0

[RFC] twin cpu bootloader design document

by Christopher Brand

Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 1 month

1
0
0 0

[Core Patch] Core: switch signal wait object to 'condition'

by Ken Liu (Arm Technology China)

Hi, I will update the wait object from 'event' to 'condition'. This is mainly for fixing the issue: https://developer.trustedfirmware.org/T273 'event' is actually a depth 1 semaphore, which is not good enough for signals synching case. Involve a simpler sync object 'condition' for signals (and client ACKs): https://review.trustedfirmware.org/c/trusted-firmware-m/+/712 Please help to check if you are interested in it. Thanks -Ken

6 years, 1 month

1
0
0 0

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi Alan, Expected to be merged before end of Mar 13th if there is no more raised concern ;) -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Tuesday, March 12, 2019 11:27 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' > is happening > > Yay! When? > > > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf- > m(a)lists.trustedfirmware.org> wrote: > > > > Hi TF-M Subscribers, > > The branch 'feature-ipc' is going to be merged into 'master', and here is the > patch: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > > > After the merging, the IPC feature will be available in the 'master' branch, > future updates on the IPC part will happen in 'master' branch, too. > > For those patches pushed towards 'feature-ipc' will be reviewed and we > suggest push new patchset to 'master' branch. > > > > Please reply to this thread without hesitation if there are any questions. > > > > Thanks. > > > > -Ken > > -- > > 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

6 years, 1 month

1
0
0 0

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by DeMars, Alan

Yay! When? > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi TF-M Subscribers, > The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. > For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. > > Please reply to this thread without hesitation if there are any questions. > > Thanks. > > -Ken > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi TF-M Subscribers, The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. Please reply to this thread without hesitation if there are any questions. Thanks. -Ken

6 years, 1 month

1
0
0 0

TF-M v1.0-Beta Blog

by Shebu Varghese Kuriakose

Hi, Here is a blog on the recent TF-M tag v1.0-Beta and how it enables PSA certification https://www.trustedfirmware.org/blog/Trusted-Firmware-M-v10-Beta-Enabling-P… Regards, Shebu

6 years, 1 month

1
0
0 0

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: >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Oh, and a little terminology comment about the Trusted non-volatile (NV) counters. This section should use "increase" and "decrease" not "increment" and "decrement". There is no requirement that the counter only be incremented (having 1 added to the value), only that it be set to a larger value than the current value. You should probably also add a discussion as to how testing will be done with a HW security counter. Again, my suggestion is to not add an additional counter, but just use the existing version field (minus the build number) as the security counter value. David

6 years, 1 month

1
0
0 0

Trusted boot - rollback protection

by Tamas Ban

Hi all, 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… Comments are welcome! Regards Tamas Ban

6 years, 1 month

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Andrew Thoelke

Hi Alan, I can answer this from the PSA Firmware Framework specification point of view, Ken (or others in the TF-M team) can clarify how closely the TF-M behaviour matches this. In the manifest each service has a "signal" attribute which is a C identifier that is given the signal value for that service. The value is allocated by the TF-M tools and should be available to the SP source code via a generated header file - the specification places these definitions in the psa_manifest/<manifestfilename>.h header file, matching the name of the manifest file itself. When the SP receives a set of signals from psa_wait(), it can identify which signals are asserted using these identifiers to test the signal bits. The example RoT Service in Appendix D of the PSA Firmware Framework demonstrates this. Regards, Andrew -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 08 March 2019 13:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] multiple services within the same SP In a multi-service SP, how does the SP know which SID has been used to connect to it? -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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, 1 month

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Ken Liu (Arm Technology China)

Hi Alan, Services are listed in SP. SPM could enumerate the services in a SP by the list. You can check the member variable ' service_list' of ' tfm_spm_ipc_partition_t' to know details. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Friday, March 8, 2019 9:52 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] multiple services within the same SP > > In a multi-service SP, how does the SP know which SID has been used to connect > to it? > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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, 1 month

1
0
0 0

multiple services within the same SP

by DeMars, Alan

In a multi-service SP, how does the SP know which SID has been used to connect to it?

6 years, 1 month

1
0
0 0

Re: [TF-M] META: TF-M Mailing list configuration

by Bill Fletcher

Hi David, Thanks for raising this. I'll contact you directly to review the Mailman configuration. Regards Bill On Thu, 28 Feb 2019, 05:04 David Brown via TF-M, < tf-m(a)lists.trustedfirmware.org> wrote: > I have noticed that this mailing list seems to be configured in a > non-ideal way. > > Primarily, the messages are sent from the list address itself, and a > reply-to header is inserted for the original sender. This at least > often will allow someone to reply to the original sender. > > There are a few problems with this. One is that this tends to break > messages that have been copied to more than one list, especially for > recipients who subscribe to both lists. Admittedly it is better than > the all-to-common practice of setting Reply-to to the list itself, > which effectively steals all replies from any other recipients or > lists that were originally included. > > Secondly, however, this kind of violates the intent of the reply-to > field, which was intended for the originator of the message to be able > to give an alternative address they wish for replies to go to. > > I don't know how this list is hosted, and usually this kind of > configuration results from an ISP that rejects messages. But, I know > a lot of mailing lists are managed with mailman without these > problems, so it should be possible to get this working in a more > homogenous way. > > Lists admins, feel free to contact me if you want any assistance in > trying to configure the list better. > > Thanks, > David > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 1 month

1
0
0 0

META: TF-M Mailing list configuration

by David Brown

I have noticed that this mailing list seems to be configured in a non-ideal way. Primarily, the messages are sent from the list address itself, and a reply-to header is inserted for the original sender. This at least often will allow someone to reply to the original sender. There are a few problems with this. One is that this tends to break messages that have been copied to more than one list, especially for recipients who subscribe to both lists. Admittedly it is better than the all-to-common practice of setting Reply-to to the list itself, which effectively steals all replies from any other recipients or lists that were originally included. Secondly, however, this kind of violates the intent of the reply-to field, which was intended for the originator of the message to be able to give an alternative address they wish for replies to go to. I don't know how this list is hosted, and usually this kind of configuration results from an ISP that rejects messages. But, I know a lot of mailing lists are managed with mailman without these problems, so it should be possible to get this working in a more homogenous way. Lists admins, feel free to contact me if you want any assistance in trying to configure the list better. Thanks, David

6 years, 1 month

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Antonio De Angelis

Hi Thomas, Thanks for the feedback. An additional question from me to understand better the issue: are you rebuilding RTX from source, not using the pre-built binaries distributed with CMSIS_5? Since this commit: https://github.com/ARM-software/CMSIS_5/commit/8bce76b03565359f31cd20ed86c2… CMSIS_5 has changed from using __DOMAIN_NS to DOMAIN_NS macro for better MISRA compliance. I think to officially support newer releases of CMSIS, we should update our instructions and define DOMAIN_NS in addition to __DOMAIN_NS, as this define will come into picture for integrations which actually rebuild RTX from the CMSIS_5 repo sources. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 26 February 2019 09:58 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] SecureFault when starting the OS Thanks Miklos and Antonio, You were both spot on. Turned out I had not define DOMAIN_NS=1, which change the last byte from FD to BC. I need to figure out why I need to add that when the documentation says __DOMAIN_NS=1 should be sufficient. Cheers, /Thomas Den 2019-02-25 kl. 17:13, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10). > > In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md . > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: 25 February 2019 15:34 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SecureFault when starting the OS > > In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. > > I'm now running into an issue where I get a SecureFault when attempting to start the OS. > > The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. > > SFSR indicates that it is an INVER (Invalid Exception Return): > --- > Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: > 0 Error has not occurred. > 1 Error has occurred. > -- > > LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. > > What am I missing here? > > Is the OS supposed to be started from NS mode? > > I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, > ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. > > Thanks, > /Thomas > > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 > SE-750 23 Uppsala, SWEDEN > Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 > E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> > Website: www.iar.com <http://www.iar.com> > Twitter: www.twitter.com/iarsystems > <http://www.twitter.com/iarsystems> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > 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. -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- 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

Re: [TF-M] SecureFault when starting the OS

by Thomas Törnblom

Thanks Miklos and Antonio, You were both spot on. Turned out I had not define DOMAIN_NS=1, which change the last byte from FD to BC. I need to figure out why I need to add that when the documentation says __DOMAIN_NS=1 should be sufficient. Cheers, /Thomas Den 2019-02-25 kl. 17:13, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10). > > In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md . > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M > Sent: 25 February 2019 15:34 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SecureFault when starting the OS > > In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. > > I'm now running into an issue where I get a SecureFault when attempting to start the OS. > > The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. > > SFSR indicates that it is an INVER (Invalid Exception Return): > --- > Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: > 0 Error has not occurred. > 1 Error has occurred. > -- > > LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. > > What am I missing here? > > Is the OS supposed to be started from NS mode? > > I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, > ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. > > Thanks, > /Thomas > > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 > SE-750 23 Uppsala, SWEDEN > Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 > E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> > Website: www.iar.com <http://www.iar.com> > Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > 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. -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 2 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Antonio De Angelis

Hi Thomas, As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10). In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md . Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 25 February 2019 15:34 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] SecureFault when starting the OS In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. I'm now running into an issue where I get a SecureFault when attempting to start the OS. The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. SFSR indicates that it is an INVER (Invalid Exception Return): --- Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: 0 Error has not occurred. 1 Error has occurred. -- LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. What am I missing here? Is the OS supposed to be started from NS mode? I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. Thanks, /Thomas *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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

Re: [TF-M] SecureFault when starting the OS

by Miklos Balint

Hi Thomas, According to TF-M's design, an RTOS is meant to be started/run in NS. If a non-secure SVC handler is called from thread mode (PSP, no FP, default stacking), the value of LR should be 0xFFFF_FFBC on exception entry. In my experience some v7-M RTOS implementations don't save the EXC_RETURN value on SVC entry but have a default value hard-coded at SVC exit. In a v7-M system the default EXC_RETURN value (assuming no SVC from handlers, and PSP used for thread mode) would be 0xFFFF_FFFD as you describe below, but that's not the case for a NS RTOS in v8-M. (The two bits that are different are EXC_RETURN.S (bit [6]) to indicate NS stack, and EXC_RETURN.ES (bit [0]) to indicate that the Exception was taken to NS) A recommended and future-proof solution is for the RTOS to save the EXC_RETURN value stored in LR on SVC entry, and when returning from the SVC, to restore that and branch, or, if a switch is needed from MSP to PSP, to set EXC_RETURN.SPSEL as needed, but leave the rest of the EXC_RETURN value unchanged. Let me know if this helps, or please provide further details if I failed to catch the root cause. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 25 February 2019 16:34 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] SecureFault when starting the OS In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. I'm now running into an issue where I get a SecureFault when attempting to start the OS. The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. SFSR indicates that it is an INVER (Invalid Exception Return): --- Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: 0 Error has not occurred. 1 Error has occurred. -- LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. What am I missing here? Is the OS supposed to be started from NS mode? I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. Thanks, /Thomas *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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

SecureFault when starting the OS

by Thomas Törnblom

In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code. I'm now running into an issue where I get a SecureFault when attempting to start the OS. The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault. SFSR indicates that it is an INVER (Invalid Exception Return): --- Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are: 0 Error has not occurred. 1 Error has occurred. -- LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception. What am I missing here? Is the OS supposed to be started from NS mode? I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs. Thanks, /Thomas *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 2 months

1
0
0 0

Some comments on twincpu mailbox design

by David Hu (Arm Technology China)

Hi Danny, Could you please check my comments on [Mailbox design](https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/mailbo… in below? I’d like to discuss about some high-level designs at the very first time. We can discuss about details later. 😊 1. As designed in Concepts section, secure core has a single dispatcher thread, which is the main thread on the secure core. AFAIK, there is no such main thread in current TF-M Inter-Process Communication model implementation. Do you mind taking a look at the section "Interaction in thread model" in our [TF-M presentation](https://events.linuxfoundation.org/wp-content/uploads/2017/12… On the other hand, implementing a dedicated thread in TF-M to handling the mailbox events can be a solution. But it might also bring some difficulties in implementation. I'd like to discuss in detail with Transport Layer together. 2. I like the concept of mailbox event. One of the key points is, after the information carried via mailbox arrives in TF-M, how to deliver it to TF-M core. We can have further discussions on the details. 3. PSA Firmware Framework specifies the parameters and return value for PSA Client APIs. Do you think if it is necessary to cover the mailbox message structure containing information of parameters and return value in mailbox design? Thank you. Best regards, Hu Ziji

6 years, 2 months

2
4
0 0

Re: [TF-M] What is the behavior of SPM between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`

by Ken Liu (Arm Technology China)

Hi Alan, From my point of view, TZ_StoreContext_S() indicates the non-secure thread accesses secure service is getting switching out, no one should access secure services before a calling of TZ_LoadContext_S(). This case could be covered in below condition in PSA FF client APIs (Picked on line from page 49 of PSA FF 1.0 beta0): "Calling psa_connect() is a fatal error and will not return if any of the following conditions are met: * ... * The caller is not authorized to access the RoT Service, see RoT Service access control on page 28. * ..." Pining the calling non-secure thread is the proper way - which means, 'Does not return' to the non-secure thread in this case. There should be no such an API to peek the status of SPM from caller out of SPM. And there should be a similar API for SPM (only) to retrieve the current MemoryID (or information could be represented as MemoryID). BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Thursday, February 21, 2019 10:54 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] What is the behavior of SPM between `TZ_StoreContext_S()` and > `TZ_LoadContext_S()` > > Are calls to psa_connect/call/close allowed after `TZ_StoreContext_S()` has > been called but before `TZ_LoadContext_S()` is called? If not, does that result in > a panic or simply error return codes? > > Is there a secure-side SPM API that can be invoked from a custom veneer > function to determine if the SPM is in the zone between `TZ_StoreContext_S()` > and `TZ_LoadContext_S()`? > > Is there an API that returns the current MemoryId? > > Alan > -- > 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

What is the behavior of SPM between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`

by DeMars, Alan

Are calls to psa_connect/call/close allowed after `TZ_StoreContext_S()` has been called but before `TZ_LoadContext_S()` is called? If not, does that result in a panic or simply error return codes? Is there a secure-side SPM API that can be invoked from a custom veneer function to determine if the SPM is in the zone between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`? Is there an API that returns the current MemoryId? Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] Musca-A SAU setup issues

by Mate Toth-Pal

Hi Thomas, (The code snippets are from the commit with hash 5c1756fbab6097f5688583d11dea5d1271d2d774 on https://review.trustedfirmware.org . I only added some comments at certain points) This symptom is usually caused by a misconfigured MPC. The MPC initialisation is also called from platform\ext\target\musca_a\spm_hal.c: ---------- 8< ---------- void tfm_spm_hal_init_isolation_hw(void) { /* Configures non-secure memory spaces in the target */ sau_and_idau_cfg(); mpc_init_cfg(); /* <- initialise MPC */ ppc_init_cfg(); } ---------- >8 ---------- Looking at mpc_init_cfg: ---------- 8< ---------- void mpc_init_cfg(void) { /* ... */ Driver_QSPI_MPC.Initialize(); Driver_QSPI_MPC.ConfigRegion(memory_regions.non_secure_partition_base, memory_regions.non_secure_partition_limit, ARM_MPC_ATTR_NONSECURE); /* ... */ /* Lock down the MPC configuration */ Driver_QSPI_MPC.LockDown(); /* ... */ /* Add barriers to assure the MPC configuration is done before continue * the execution. */ __DSB(); __ISB(); } ---------- 8< ---------- It is possible to change the MPC behaviour, to raise a bus fault on invalid access instead of the RAZ/WI behaviour, by setting the CFG_SEC_RESP bit in the MPC's control register. You should do something like this after Driver_QSPI_MPC initialisation (see https://developer.arm.com/products/architecture/cpu-architecture/m-profile/… ): ---------- 8< ---------- uint32_t mpc_ctrl; Driver_QSPI_MPC.GetCtrlConfig(&mpc_ctrl); Driver_QSPI_MPC.SetCtrlConfig(mpc_ctrl | 0x10); ---------- 8< ---------- If you don't get the bus fault after this, further troubleshooting is needed. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 15 February 2019 15:57 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Musca-A SAU setup issues I am working on porting TF-M to the IAR Embedded Workbench for ARM (EWARM) toolchain and I'm having some issues getting it to start properly. I started out using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 CMSIS packs and I've had to fix things in all of the packs to make the project build with our compiler, some things just to add our tools, some things that were just gcc:isms that are non standard-C. The TF-M code is based on a snapshot of https://git.trustedfirmware.org/trusted-firmware-m.git repository of the following hash: 5c1756fbab6097f5688583d11dea5d1271d2d774 I know that some of these packs are old and I'm also working on a port of the bits on trustedfirmware.org, but I would like to bring the old version up first. The (current) issue I have is that the NS code region becomes inaccessible from the secure part after setting the SAU up and I assume I am missing something. in tfm_core_init() there are calls to: --- tfm_spm_hal_init_isolation_hw(); configure_ns_code(); --- tfm_spm_hal_init_isolation_hw() calls sau_and_idau_cfg(), which sets up: --- /* Configures SAU regions to be non-secure */ SAU->RNR = TFM_NS_REGION_CODE; SAU->RBAR = (memory_regions.non_secure_partition_base & SAU_RBAR_BADDR_Msk); SAU->RLAR = (memory_regions.non_secure_partition_limit & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; --- After this piece is run, the NS vector table becomes all zeros when viewed from secure mode. This causes the configure_ns_code() call above to fail to pick up the ns_msp and ns_entry addresses, they become 0. If I swap the calls around so they become: --- configure_ns_code(); tfm_spm_hal_init_isolation_hw(); --- then ns_msp and ns_entry are picked up OK. How is this supposed to work? When the SAU is setup I get RAZ/WI when accessing NS memory from S mode, the other way around results is a security violation, which is properly handled by the SecureFault_Handler(). What am I missing? I run into other problems later, but that may very well a consequence of earlier issues. Thanks, /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- 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

Re: [TF-M] SYSTICK ownership

by DeMars, Alan

My concern was the value one would provide for the "line_num" field within the manifest. The SYSTICK uses vector 15 which I believe would correspond to "line_num" = -1. I'm not sure the design accommodates negative line_nums. Also, disabling the SYSTICK interrupt while servicing its interrupt can't be handled in the normal way user IRQs are disabled. Special case code would be required in the SPM to support the SYSTICK as a secure partition interrupt. 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: Monday, February 18, 2019 5:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SYSTICK ownership Hi Alan, From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure SYSTICK timer > and its interrupt? > If so, how is it specified in the SP manifest? > > 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

6 years, 2 months

1
0
0 0

Re: [TF-M] SYSTICK ownership

by Ken Liu (Arm Technology China)

Hi Alan, From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure SYSTICK timer > and its interrupt? > If so, how is it specified in the SP manifest? > > Alan > -- > 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

Re: [TF-M] interrupts not supported on feature-ipc branch?

by DeMars, Alan

Thanks! I'll check back. -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, February 18, 2019 5:16 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] interrupts not supported on feature-ipc branch? Hi Alan, There would be a merge to master in recent days; so master branch will support PSA IPC soon. The interrupts for IPC is under developing, you can check the roadmap to know the plan. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:37 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] interrupts not supported on feature-ipc branch? > > I guess interrupts are only supported on the master branch. > > When will the master branch support PSA IPC? > > Or, when will the feature-ipc branch support interrupts? > > 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

6 years, 2 months

1
0
0 0

Re: [TF-M] interrupts not supported on feature-ipc branch?

by Ken Liu (Arm Technology China)

Hi Alan, There would be a merge to master in recent days; so master branch will support PSA IPC soon. The interrupts for IPC is under developing, you can check the roadmap to know the plan. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:37 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] interrupts not supported on feature-ipc branch? > > I guess interrupts are only supported on the master branch. > > When will the master branch support PSA IPC? > > Or, when will the feature-ipc branch support interrupts? > > Alan > -- > 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

New PSA API proposal

by DeMars, Alan

I obtained the following benchmarks for the 3 PSA APIs psa_connect(), psa_call(), and psa_close() using the attached implementation of a Secure Partition (my_sp.c) and building both my NS application and the SPE image with -O3 optimizations: psa_connect() 2133 cycles psa_call() 2650 cycles psa_close() 2136 cycles The psa_call() numbers were achieved by passing 'MY_SP_MSG_TYPE_NULL' as the message type to my test SP, thus eliminating any invec and outvec processing from the benchmark. The secure partition had been regenerated using the attached tfm manifest to reduce the number of user-provided SPs to just 2: the feature-ipc branch's test PSA service and my test PSA service. With these benchmarks in mind and after reviewing the new PSA-compliant SST API implementations, I propose that a new, more efficient, PSA IPC API be provided for those user-facing SP service requests which require no state in the secure partition. Below is the psa_sst_common() function shared by all of the new PSA compliant sst APIS (snipped from interface/src/tfm_sst_api_ipc.c): static psa_status_t psa_sst_common(uint32_t sid, uint32_t minor_version, const psa_invec *in_vecs, size_t in_len, psa_outvec *out_vecs, size_t out_len) { psa_handle_t handle; psa_status_t status; handle = psa_connect(sid, minor_version); if (handle <= 0) { return PSA_SST_ERR_PARAM_ERROR; } status = psa_call(handle, in_vecs, in_len, out_vecs, out_len); if (status < 0) { status = PSA_SST_ERR_SYSTEM_ERROR; } psa_close(handle); return status; } I propose that the functionality and signature of 'psa_sst_common' be promoted to a formal PSA API. For lack of a better name, call this new API 'psa_ccc()', to convey the meaning that it combines the CONNECT, CALL, and CLOSE functions. Internally, the SPM would skip allocating and deallocating a handle, then pass message type 'PSA_IPC_CCC' to the SP. Here is a crude representation of how the PSA_IPC_CCC message type could be handled by a Secure Partition: case PSA_IPC_CCC: if (inuse) { psa_reply(msg.handle, PSA_CONNECTION_REFUSED); } else { inuse = 1; /* to handle potential SP pre-emption during my_sp_call() case */ r = my_sp_call(&msg); psa_reply(msg.handle, r); inuse = 0; } break; Please consider this proposal. The new API would save the overhead of entering and exiting the SP 3 times for SP service requests that require no state. Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] IRQ handling by Secure Partitions proposal

by DeMars, Alan

Miklos, Thank you for those clarifications. Sorry it's taken so long to reply. I think I now have a basic grasp of how interrupts owned by SPs are managed. Regarding item 4) below, what is the proposal for informing a calling NS thread that a service request can't complete until some future asynchronous event (ie a peripheral interrupt) occurs? Will this be in the form of special psa_call() return codes or is the SP expected to use outvecs to convey that information? How will the calling thread know when the service request can be completed? The idea of a dedicated non-secure interrupt that the SP/SPM triggers has been mentioned several times. Some kind of asynchronous callback dispatcher as hinted at in the "Concurrent secure service requests" paragraph here: https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/ Is this mechanism being designed by TFM or is this functionality going to be left to the various users of the reference PSA implementation? Should I begin designing this myself? I guess the overarching question is, does the PSA proposal support secure peripheral drivers, and if so, how? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Tuesday, February 05, 2019 8:02 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] IRQ handling by Secure Partitions proposal Hi Alan, 0, One thing to point out is that my proposal only covers the "Library" or function-call-based model that was the only one implemented on TF-M master branch at the time of writing. PSA Firmware Framework v1.0 with its IPC mechanism has its own design of how interrupts are supposed to be handled by secure threads - my proposal intends to complement that with the same functionality for the other operating model. This clarification addresses point 5 as well, I believe. 1, SPM "Acknowledges the interrupt": this is not the best wording. Actually this is very bad wording. What I meant to say is that SPM's own interrupt handler is started - which is a hardware action, not one by SPM - and SPM ISR in turn masks the interrupt line in NVIC. As you rightly point out, the peripheral itself is of no concern to SPM, that's the business for partition code, either in its own Partition ISR, or a service function. 2. This means that secure PSP is saved for the pre-empted context, set to the stack of the partition that's the owner of the interrupt line, and any additional housekeeping associated with a context switch (PSPLIM setup, isolation re-configuration, privilege setting - all according to the properties of the partition that is to be activated). Lastly, a mock context is created on the partition stack so that the Partition ISR can be activated with an exception return from the SPM ISR. 3a. The Partition ISR is activated by SPM ISR by doing an exception return to the start address of e.g. UART1_ISR() function. In order for this TF-M first needs to create the mock context mentioned in my point 2. The discussion of the stack frame in the text is meant to clarify that there are two possibilities that need to be considered: if the partition is idle, i.e. there are no ongoing service requests in its context, its stack pointer is either at a default value or - potentially - there's no stack associated with the partition. In that case a stack frame needs to be initialized and the mock context set up there. If the partition is handling a request, its original stack pointer needs to be used as the start address for the mock context used for exception return. 3b. After execution of the Partition ISR, execution is returned to the SPM ISR. At this point, SPM can decide to either re-activate the original context that had been pre-empted by the interrupt, or, can take a scheduling decision to activate a different context, e.g. the partition that had called psa_wait(). 4. The current implementation does not allow for the pre-emption of a secure context by non-secure scheduling events, but that is a limitation that could likely be lifted depending on some basic policies that have to be set up by the system integrator. In such a case the NS thread would be blocked waiting on the completion of the secure service, but a pre-emptive NS OS could schedule a different thread if the time slice of the caller thread runs out. Other options are subject to investigation at this point. ... Please let me know if any of the points I've addressed provide clarity instead of making the design more obscure, in which case I would update the design proposal with the extra information. :) And of course let me know if you have further questions. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 02 February 2019 04:29 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] IRQ handling by Secure Partitions proposal Regarding the "SPM behavior" discussion in the "Secure Partition Interrupt Handling" proposal: 1) What is meant by the SPM "Acknowledges the interrupt"? I understand "masks the hardware interrupt line" but I don't see how the SPM can know how to acknowledge a particular peripheral's interrupt. I think acknowledging the interrupt should be done by the "Partition ISR" dedicated to the interrupt, or within the corresponding SP's main loop upon return from psa_wait(). 2) What does "Sets up execution environment for the secure partition" mean, precisely? 3) Can you expand on the "Execute Partition ISR" paragraph a little? I assume you mean that, for instance, the registered UART1_isr() function is called. The discussion of the ISR stack frame I don't really follow. And from the description, I'm not sure when the SP is scheduled to run again to deal with the ISR it was waiting for. 4) A secure partition that depends on an interrupt begs the question of what happens to the NS thread that has called into the SP requesting some service that depends on a subsequent asynchronous event (ISR) to complete the request. The psa_call() function as currently implemented doesn't "block" in the traditional OS sense (ie the thread's context and state are not saved in a manner that allows another task thread to run while the psa_call() is stalled in the SPM waiting for an ISR. 5) The details of SP thread pre-emption and re-entrancy need to be described. 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

6 years, 2 months

1
0
0 0

interrupts not supported on feature-ipc branch?

by DeMars, Alan

I guess interrupts are only supported on the master branch. When will the master branch support PSA IPC? Or, when will the feature-ipc branch support interrupts? Alan

6 years, 2 months

1
0
0 0

SYSTICK ownership

by DeMars, Alan

If not used anywhere else, can a Secure Partition own the secure SYSTICK timer and its interrupt? If so, how is it specified in the SP manifest? Alan

6 years, 2 months

1
0
0 0

Musca-A SAU setup issues

by Thomas Törnblom

I am working on porting TF-M to the IAR Embedded Workbench for ARM (EWARM) toolchain and I'm having some issues getting it to start properly. I started out using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0, ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 CMSIS packs and I've had to fix things in all of the packs to make the project build with our compiler, some things just to add our tools, some things that were just gcc:isms that are non standard-C. The TF-M code is based on a snapshot of https://git.trustedfirmware.org/trusted-firmware-m.git repository of the following hash: 5c1756fbab6097f5688583d11dea5d1271d2d774 I know that some of these packs are old and I'm also working on a port of the bits on trustedfirmware.org, but I would like to bring the old version up first. The (current) issue I have is that the NS code region becomes inaccessible from the secure part after setting the SAU up and I assume I am missing something. in tfm_core_init() there are calls to: --- tfm_spm_hal_init_isolation_hw(); configure_ns_code(); --- tfm_spm_hal_init_isolation_hw() calls sau_and_idau_cfg(), which sets up: --- /* Configures SAU regions to be non-secure */ SAU->RNR = TFM_NS_REGION_CODE; SAU->RBAR = (memory_regions.non_secure_partition_base & SAU_RBAR_BADDR_Msk); SAU->RLAR = (memory_regions.non_secure_partition_limit & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; --- After this piece is run, the NS vector table becomes all zeros when viewed from secure mode. This causes the configure_ns_code() call above to fail to pick up the ns_msp and ns_entry addresses, they become 0. If I swap the calls around so they become: --- configure_ns_code(); tfm_spm_hal_init_isolation_hw(); --- then ns_msp and ns_entry are picked up OK. How is this supposed to work? When the SAU is setup I get RAZ/WI when accessing NS memory from S mode, the other way around results is a security violation, which is properly handled by the SecureFault_Handler(). What am I missing? I run into other problems later, but that may very well a consequence of earlier issues. Thanks, /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 2 months

1
0
0 0

Re: [TF-M] SPM crashes when built with any non zero optimization level

by Gyorgy Szing

Hi Alan, Please check this ticket https://developer.trustedfirmware.org/T234 Is it possible you are affected by the same issue? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 14 February 2019 06:59 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] SPM crashes when built with any non zero optimization level Is anyone else having the problem that enabling optimizations when building the secure image causes the secure partition manager to crash when entered through any of the psa_xxx() IPC veneers? Using GCC -O1, -O2, or -O3 compile options, something seems to go wrong with the SVC context. Everything behaves correctly when built with no optimizations. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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

SPM crashes when built with any non zero optimization level

by DeMars, Alan

Is anyone else having the problem that enabling optimizations when building the secure image causes the secure partition manager to crash when entered through any of the psa_xxx() IPC veneers? Using GCC -O1, -O2, or -O3 compile options, something seems to go wrong with the SVC context. Everything behaves correctly when built with no optimizations. Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: Clarification of pre-existing TFM secure service alignment with PSA APIs

by DeMars, Alan

Ken, Thank you confirming my understanding. The new NS interface code in those commits clearly demonstrate the underlying calls to psa_connect(), psa_call(), and psa_close(). Alan > On Feb 11, 2019, at 6:38 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > After PSA IPC model takes place, existing services need to be modified to support it. > The action is not a re-implement actually. The basic idea is creating an IPC SP body > and calls existing secure service functions. There are also some commits for reference: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/473/ > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/474/ > > There are IPC compatible items in roadmap reflects the plan: > https://developer.trustedfirmware.org/w/tf_m/planning/ > > Thanks > > -Ken > >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, >> Alan via TF-M >> Sent: Tuesday, February 12, 2019 9:39 AM >> To: tf-m(a)lists.trustedfirmware.org >> Subject: [TF-M] Clarification of pre-existing TFM secure service alignment with >> PSA APIs >> >> Is my understanding correct that the existing set of secure services (audit, crypto, >> sst, etc) that use the "Library" or function-call-based-model to enter the SPE are >> being redesigned to conform to the PSA IPC model, meaning that each service >> will be re-implemented as a SP with a forever loop? >> >> If so, does this mean that the existing set of NS-facing APIs associated with each >> secure service will be re-implemented as libraries that funnel all of their calls >> into the SPE through the 3 PSA IPC calls (psa_connect(), psa_call(), and >> psa_close())? >> >> 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

6 years, 2 months

1
0
0 0

Re: [TF-M] tz_context APIs

by DeMars, Alan

I'm thinking that the real concern is that the caller should be in 'privileged mode' rather than specifically in handler mode. Is this correct? If so, perhaps the caller's mode check can be converted to affirm 'privileged mode' rather than handler mode. If not, I don't understand what additional security is gained by being in handler mode. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Wednesday, February 13, 2019 6:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] tz_context APIs One fundamental reason for driving context changes from handler mode is to have privilege and isolation control when switching contexts. So it all boils down to the requirements of a particular deployment. If there is no compartmentalization and privilege control in NSPE, i.e. all NS threads and the OS have identical access policies to secure assets, it should be possible to lift this requirement and accept NSPE context change notifications that transition from NSPE to SPE in thread mode. This, however, only results in a performance improvement if SPE also bypasses handler mode for this operation, requiring slightly more than skin-deep modifications in TF-M to handle all possible (ab)uses of the secure context management feature. I think this can be a valid choice for a specific implementation, but support for this as a configuration switch in the upstream and threat modelling the alternate setting would be a stretch in our team's current roadmap. /M -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 13 February 2019 05:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tz_context APIs Why do all the APIs declared in tz_context.h need to be called from NS Handler mode? Is this a hard requirement or can it be configured 'OFF'? For performance reasons, our OS doesn't trap into handler mode to perform thread management like creation, scheduling, and context switching. Having to switch to handler mode without a very compelling reason seems like unnecessary overhead in performance-critical code. 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

6 years, 2 months

1
0
0 0

Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management

by DeMars, Alan

Hi Miklos, Thank you for the roadmap info. I’ll check this out and provide feedback in a separate email. Yes, my concern is regarding the few dozen cycles of overhead. No, this is not a major limitation but it does seem needlessly wasteful to me. I think your proposal to alter the behavior of TZ_LoadContext_S as you suggest is an excellent idea. My understanding of the TZ_LoadContext_S semantics is “until the next TZ_LoadContext_S call, all calls into the SPM will be from this context”. If that is a correct understanding, then assuming the previously active MemoryId should be stored seems like a safe and always true inference. Alan > On Feb 7, 2019, at 2:42 AM, Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. > Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans. > > For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: > https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu… > > Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. > Are you concerned that this overhead is a major limitation? > > If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. > This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. > Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point. > > /M > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 03 February 2019 15:18 > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org > Subject: Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management > > Ken, > > Thank you for your prompt response. Please see my replies below. > > Alan > >> Hi Alan, >> The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. > > Is their a feature rollout schedule that I can follow? > >> The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. > > To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing. > >> The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. >> >> -Ken >> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Sunday, February 3, 2019 9:17 AM >>> To: tf-m(a)lists.trustedfirmware.org >>> Subject: [Tf-m] Non-secure Client Management >>> >>> Regarding the Non-secure Client Management proposal: >>> >>> >>> https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem >>> ent/ >>> >>> I notice that the veneers for the proposed APIs are in s_veneers.o. >>> Does this mean that the proposal has been adopted and implemented? Is >>> it functional in the current feature-ipc branch? >>> >>> I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: >>> Is it expected that each context switch in the NS world will be >>> signaled by calls to each of these APIs indicating the "entering" >>> context and "leaving" context respectively? If so, then why not >>> collapse these two APIs into one called >>> TZ_SwitchContext__S() and pass both the "entering" and "leaving" >>> TZ_MemoryId_t's as arguments? >>> >>> Or is TZ_StoreContext_S() only to be called when a NS context will >>> never call into the SPM again? If that is the case, why isn't >>> TZ_FreeModuleContext_S() sufficient? >>> >>> Regarding the "Concurrent secure service requests" discussion, what >>> does "a non-secure client is blocked on an asynchronous secure service completion"? >>> Would this be achieved by a special return status from psa_call() >>> indicating that the current service request is in process and will >>> complete later on? The psa_call() calling thread would then block on >>> a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet? >>> >>> Alan > > -- > 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] [Tf-m] [EXTERNAL] Re: Non-secure Client Management

by DeMars, Alan

Miklos, In regards to the roadmap, just to confirm my understanding, does the "[TF-M Core] Interrupt Handling Enhancements" bullet due in Q1`19 refer to the interrupt support as described in section 3.4 "Secure peripheral drivers" of the PSA Firmware Framework document? When will SP pre-emption and blocking be supported? A secure peripheral driver that doesn't allow the NS thread to block while waiting for something to complete is a non-starter for us. As well, a SP thread that can't be pre-empted by a higher priority NS thread is almost as unpalatable for us. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Thursday, February 07, 2019 2:43 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management Hi Alan, https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans. For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu… Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. Are you concerned that this overhead is a major limitation? If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point. /M -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 03 February 2019 15:18 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management Ken, Thank you for your prompt response. Please see my replies below. Alan > Hi Alan, > The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. Is their a feature rollout schedule that I can follow? > The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing. > The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. > > -Ken > >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> DeMars, Alan via TF-M >> Sent: Sunday, February 3, 2019 9:17 AM >> To: tf-m(a)lists.trustedfirmware.org >> Subject: [Tf-m] Non-secure Client Management >> >> Regarding the Non-secure Client Management proposal: >> >> >> https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem >> ent/ >> >> I notice that the veneers for the proposed APIs are in s_veneers.o. >> Does this mean that the proposal has been adopted and implemented? Is >> it functional in the current feature-ipc branch? >> >> I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: >> Is it expected that each context switch in the NS world will be >> signaled by calls to each of these APIs indicating the "entering" >> context and "leaving" context respectively? If so, then why not >> collapse these two APIs into one called >> TZ_SwitchContext__S() and pass both the "entering" and "leaving" >> TZ_MemoryId_t's as arguments? >> >> Or is TZ_StoreContext_S() only to be called when a NS context will >> never call into the SPM again? If that is the case, why isn't >> TZ_FreeModuleContext_S() sufficient? >> >> Regarding the "Concurrent secure service requests" discussion, what >> does "a non-secure client is blocked on an asynchronous secure service completion"? >> Would this be achieved by a special return status from psa_call() >> indicating that the current service request is in process and will >> complete later on? The psa_call() calling thread would then block on >> a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet? >> >> Alan -- 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] tz_context APIs

by Miklos Balint

One fundamental reason for driving context changes from handler mode is to have privilege and isolation control when switching contexts. So it all boils down to the requirements of a particular deployment. If there is no compartmentalization and privilege control in NSPE, i.e. all NS threads and the OS have identical access policies to secure assets, it should be possible to lift this requirement and accept NSPE context change notifications that transition from NSPE to SPE in thread mode. This, however, only results in a performance improvement if SPE also bypasses handler mode for this operation, requiring slightly more than skin-deep modifications in TF-M to handle all possible (ab)uses of the secure context management feature. I think this can be a valid choice for a specific implementation, but support for this as a configuration switch in the upstream and threat modelling the alternate setting would be a stretch in our team's current roadmap. /M -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 13 February 2019 05:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] tz_context APIs Why do all the APIs declared in tz_context.h need to be called from NS Handler mode? Is this a hard requirement or can it be configured 'OFF'? For performance reasons, our OS doesn't trap into handler mode to perform thread management like creation, scheduling, and context switching. Having to switch to handler mode without a very compelling reason seems like unnecessary overhead in performance-critical code. Alan -- 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

tz_context APIs

by DeMars, Alan

Why do all the APIs declared in tz_context.h need to be called from NS Handler mode? Is this a hard requirement or can it be configured 'OFF'? For performance reasons, our OS doesn't trap into handler mode to perform thread management like creation, scheduling, and context switching. Having to switch to handler mode without a very compelling reason seems like unnecessary overhead in performance-critical code. Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] Clarification of pre-existing TFM secure service alignment with PSA APIs

by Ken Liu (Arm Technology China)

Hi Alan, After PSA IPC model takes place, existing services need to be modified to support it. The action is not a re-implement actually. The basic idea is creating an IPC SP body and calls existing secure service functions. There are also some commits for reference: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/473/ https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/474/ There are IPC compatible items in roadmap reflects the plan: https://developer.trustedfirmware.org/w/tf_m/planning/ Thanks -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Tuesday, February 12, 2019 9:39 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] Clarification of pre-existing TFM secure service alignment with > PSA APIs > > Is my understanding correct that the existing set of secure services (audit, crypto, > sst, etc) that use the "Library" or function-call-based-model to enter the SPE are > being redesigned to conform to the PSA IPC model, meaning that each service > will be re-implemented as a SP with a forever loop? > > If so, does this mean that the existing set of NS-facing APIs associated with each > secure service will be re-implemented as libraries that funnel all of their calls > into the SPE through the 3 PSA IPC calls (psa_connect(), psa_call(), and > psa_close())? > > Alan > -- > 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

Clarification of pre-existing TFM secure service alignment with PSA APIs

by DeMars, Alan

Is my understanding correct that the existing set of secure services (audit, crypto, sst, etc) that use the "Library" or function-call-based-model to enter the SPE are being redesigned to conform to the PSA IPC model, meaning that each service will be re-implemented as a SP with a forever loop? If so, does this mean that the existing set of NS-facing APIs associated with each secure service will be re-implemented as libraries that funnel all of their calls into the SPE through the 3 PSA IPC calls (psa_connect(), psa_call(), and psa_close())? Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] How to run PSA API compliance tests with TF-M SST service

by Marc Moreno Berengue

Hi all, All the patches needed to pass all the PSA API Compliance tests have been merged into TF-M master branch, so there is no need for step [2] below, just checkout the TF-M master branch. Thanks, Marc Moreno ________________________________ From: Marc Moreno Berengue Sent: 01 February 2019 18:17 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [TF-M] How to run PSA API compliance tests with TF-M SST service <mailto:nd@arm.com>Hi all, The Secure Storage (SST) service has been updated to align it with the PSA Protected Storage APIs version 1.0. There are a set of patches which implements this change. Please, find more information about those changes in the following ticket: https://developer.trustedfirmware.org/T218 It's possible to run the PSA API Compliance tests (https://github.com/ARM-software/psa-arch-tests/tree/master/api-tests/dev_ap…) with the TF-M SST service by following the instructions below. (The instructions assume that psa-arch-tests and trusted-firmware-m directories are at the same level in the filesystem): 1. Checkout https://github.com/ARM-software/psa-arch-tests/ 2. Checkout https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/589/ 3. Copy the `interface/include/psa_protected_storage.h` to `interface/include/psa/protected_storage.h` as this is the header name expected by the PSA API Compliance tests 4. Build the SST tests for the PSA API compliance as described in the `psa-arch-tests/api-tests` for one of the supported targets, providing the include path of the TF-M interface (i.e. trusted-firmware-m/interface/include). Set crypto and internal trusted storage as not implemented in `psa-arch-tests/api-tests/platform/targets/<TARGET_NAME>/Makefile`. Set PSA_CRYPTO_IMPLEMENTED:=0 and PSA_INTERNAL_TRUSTED_STORAGE_IMPLEMENTED:=0 * The list of tests being run is specified in the file `psa-arch-tests/api-tests/dev_apis/protected_storage/testsuite.db` * For example, this command will build the tests for AN521 "./tools/scripts/setup.sh --target tgt_dev_apis_tfm_an521 --toolchain ARMCLANG --cpu_arch armv8m_ml --verbose 2 --suite protected_storage --include ../../trusted-firmware-m/interface/include --archive_tests" 5. Build TF-M by using the ConfigPsaApiTest.cmake, enabling the PSA API Compliance tests for SST service by adding the following cmake switch during the configuration step: "-DPSA_API_TEST_SECURE_STORAGE=ON" * For example, this command will build the TF-M + NS app with PSA API Protected Storage tests for AN521 "cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../ConfigPsaApiTest.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DPSA_API_TEST_SECURE_STORAGE=ON ../" This will make our NS test app run a subset of the PSA API compliance tests for SST service. Thanks, Marc Moreno

6 years, 2 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: generated header files

by DeMars, Alan

Mate, Thank you! I was able to regenerate from an edited .yaml file and get exactly what I needed. Alan > On Feb 7, 2019, at 11:47 PM, Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > Currently the generation of these files is a manual step that should be done prior to build. > > The script that does the generation is the tools/tfm_parse_manifest_list.py python script. The script has to be run with no command line parameters from the TF-M source root dir. The location of two files, tools\tfm_generated_file_list.yaml and tools\tfm_manifest_list.yaml are hardcoded into the script, and they specify the files the script works on. > > tfm_manifest_list.yaml contains the list of partition manifest files. These yaml files provide the information that template files have to be filled with. > tfm_generated_file_list.yaml contains the list of files to be generated. The script assumes, that for each <generated_file_path>/<generated_file_name> there is a file <generated_file_path>/<generated_file_name>.template file, which is used as a template for generation. > > Please note, that the current version of this script on master contains a custom parser and substituting code, however we have a plan to replace it to the Jinja2 template parser engine. Please see the proposal here: https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_ji… > > Regards, > Mate > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 07 February 2019 22:35 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] generated header files > > I'm using the feature-ipc branch and I notice a lot of these warnings in TF-M header files: > > /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ > > When are these files generated? I assume they're derived from associated manifest files. > > When I use cmake to create a "ConfigCoreIPC.cmake" build area, I don't see any header files being generated in the process. Any changes I've made to header files with these warnings are still present. Is there a TF-M cmake configuration that regenerates these files? If so, how do I invoke it so I can more properly reconfigure a custom SP? > > 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

6 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M