- TF-M - lists.trustedfirmware.org

Invitation: TF-M Tech Forum @ Thu 19 Dec 2019 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+17207072699,,5810428000# US (Denver)Dial by your location +1 646 558 8656 US (New York) +1 720 707 2699 US (Denver) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 19 Dec 2019 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MnVjODY4YmlscGlxbHU2b… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years, 1 month

1
0
0 0

Coding guideline

by Reinhard Keil

Has there been any conclusion on coding guidelines. IMHO a 80-char restriction is irrelevant with today's screens/editors - it comes from the teletype time where 80 characters was the natural limit on CRT or punch card. MISRA in contrast is industry standard and a fundamental requirement in many projects. What is the progress here? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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

Level 2/Level 3 Isolation requires IPC?

by Reinhard Keil

I have heard that Level 2/Level 3 isolation with TF-M requires Inter-Process Communication (IPC) mode. It does not work with Secure Function Call (SFC) mode (aka Library mode). Is it correct, and why does Level2/Level 3 isolation require IPC? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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] irq handling in library mode

by Reinhard Keil

I would argue that "IRQ handling" should just be standard v8M hardware behaviour for the following rational: * IRQ routines should be short and simple by nature - it is therefore relative easy to fully verify it and ensure that there are no side effects. * IRQ should be therefore executed in handler mode using MSP, no MPU protection, only protection via SAU, PPC, MPC. Another reason of this relaxed approach is the usage of DMA. * DMA is frequently controlled by IRQ * DMA also bypasses MPU, therefore same behaviour as IRQ. Overall this approach ensures simple, fast IRQ execution (sales argument of v8M) and reduces risk software glitches in TF-M Core. What is wrong with that approach? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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] Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I will be collecting for new review comments till this Friday. If there were no new comments, I will get the patches merged after addressing the existing comments. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:02 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Support for optional build for secure partitions and test suites Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin -- 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] irq handling in library mode

by Edison Ai (Arm Technology China)

Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: "If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location." Let's start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: * SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: SP2 stack pointer ---> Caller_partition_indx(handler) Partition_sate(handler) * SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. SP2 stack pointer ---> Partition_state(interrupted) Caller_partition_indx(handler) Partition_sate(handler) And after SP2 is interrupted by SP3, its partition status will be changed to "SPM_PARTITION_STATE_SUSPENDED". So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 1 month

1
0
0 0

Re: [TF-M] MPU issues, was Re: Regression test issues with IAR port

by Edison Ai (Arm Technology China)

Hi Thomas, What I can see from your description is that the problem should is caused the MPU configure. You are working on the isolation level 2 model by using ConfigRegressionIPCTfmLevel2 configure file. In isolation level 2, PSA FF says this: "the PSA Root of Trust is also protected from access by the Application Root of Trust". You can see more detail about the isolation information from PSA FF with this link: https://pages.arm.com/psa-resources-ff.html?_ga=2.156169596.61580709.154261…. So, we need to configure MPU(MSUCA_A board which you are using) for APP RoT to limit the source the APP RoT can access in isolation level 2. You can see from code: __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } The psa_wait() is put in the "SFN" region, and the "SFN" region in put in the "TFM_UNPRIV_CODE" section. You can see the information about the "TFM_UNPRIV_CODE" in platform/ext/common/armclang/tfm_common_s.sct. You can refer tfm_spm_mpu_init() in platfrom/ext/target/musca_a/spm_hal.c. There are some MPU region we need to configure for APP RoT in isolation level 2, include the "TFM_UNPRIV_CODE". If you are interested, you can see some detail about the design of isolation level 2 from here: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… Please check this first. If cannot work, please feel free to tell us. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, December 13, 2019 4:25 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MPU issues, was Re: Regression test issues with IAR port Next issue. For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why. It happens in the psa_wait() call in: --- int32_t tfm_irq_test_1_init(void) { tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ); #ifdef TFM_PSA_API psa_signal_t signals = 0; while (1) { signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK); --- The exact point of the exception is the SVC call in: --- __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } --- The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution." The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access. If I don't enable the mpu (just skipping the enable call) then all tests run without problems. I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception. The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works. This is on a Musca A by the way. Ideas? -- *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

2
2
0 0

irq handling in library mode

by lg

Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

6 years, 2 months

1
0
0 0

Re: [TF-M] Adding Cypress PSoC64 platform support

by David Hu (Arm Technology China)

Hi all, After several rounds of review, I'd like to merge Cypress PSoC 64 support on master branch this Tuesday. If you have more comments or opinions, please share them before Tuesday. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, December 7, 2019 4:13 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Adding Cypress PSoC64 platform support Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 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. -- 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] Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

Hi all, I'd like to merge the patch set https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… soon if no further comments. Please share your comments before this Tuesday. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, December 12, 2019 11:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review the patch set to extract duplicated template files from platforms Hi all, I submit a patch set to extract the duplicated identical template files dummy_xxx.c from targets and put them under platform/ext/common/template folder. The purpose is to collect a common template of booting/attestation example for platforms and each platform doesn't need to keep a copy under its folder anymore. Since it is a general change related to all platforms using template files, I'd like to ask for review here. Any comments would be appreciated. Please check the patch details in https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… The background is described in https://developer.trustedfirmware.org/T539. Best regards, Hu Ziji -- 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M