- TF-M - lists.trustedfirmware.org

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Ken Liu (Arm Technology China)

Hi Reinhard, Guess this diagram for a long time ago design since the latest version there is no need for NS SVC. (Check diagram attached in the ticket). I think the existing library model implementation is almost the one you described, just some points: - We use a secure SVC in SPM for sanitization input/output buffers. - We do secure partition maintenance in SPM (forward call, maintain state). The TZ API implementation under SFC is for the purpose that some services have bound the client with policies so they need to know which client is calling. It can be skipped if there is no such client-orient policy. And one thing to mention, even we propose to use locks in RTOS for locking the interface, there would be a chance that some RTOS has a limitation on these lock APIs, or someone just acts as an attacker who skips the necessary locking operations, then we need to provide some detection in the secure side as countermeasures, and this part needs to be documented to remind users that, please make sure there is only one ongoing secure call or a panic is generated. Then it would be RTOS' choice to decide if they want to avoid this panic by locking. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, December 12, 2019 11:22 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution) As the picture got lost, I did create also https://developer.trustedfirmware.org/T615 This contains the picture Reinhard 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

4 years, 10 months

1
0
0 0

MPU issues, was Re: Regression test issues with IAR port

by Thomas Törnblom

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>

4 years, 10 months

1
0
0 0

TF-M Technical Forum call - 19th December

by Anton Komlev

Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev

4 years, 10 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Gyorgy Szing

Hi, Sorry the image did not got trough. One way to share the image could be to create a ticket here https://developer.trustedfirmware.org/maniphest/ where the image can be uploaded. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 12 December 2019 13:13 To: tf-m(a)lists.trustedfirmware.org Cc: Bruno Mendes <Bruno.Mendes(a)arm.com> Subject: [TF-M] Simplify RTOS / TF-M interface (single thread execution) When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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

4 years, 10 months

2
1
0 0

Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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.

4 years, 10 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by DeMars, Alan

Ken, Task scheduling (context switching) in our RTOS is always performed in thread mode, even when asynchronous pre-emption occurs resulting from an ISR readying a higher priority task. All kernel-managed interrupts are routed to a common interrupt dispatcher that, just prior to returning from an interrupt, will invoke the task scheduler when it determines that there are no more interrupts pending and there is scheduling work to do. In that case, an artificial interrupt context is created so that thread mode can be "returned to" from handler mode. The task scheduler is then invoked in thread mode from the stack of the pre-empted task. Regarding secure interrupts, our use cases only employ secure interrupts as a consequence of a psa_call() initiating a process that completes when an interrupt goes off sometime later. Rather than spin-waiting for the interrupt-completion signal, or parking in a WFI, we simply return from the psa_call() with a special return code indicating that the process has started and that the calling thread will be notified of completion by the secure callback mechanism I described at the conference in Lyon. The calling thread then pends on a semaphore. When the secure interrupt goes off later on, a dedicated non-secure interrupt is triggered that ultimately ends up posting the semaphore that the NS thread is pended on. Upon returning from the pend, the NS thread then re-enters the SP (using psa_call()) to complete the transaction. 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, December 10, 2019 8:04 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Secure Interrupt handling - RE: TF-M technical Forum slides and recording Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- 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

4 years, 10 months

2
1
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by lg

Hi Edison, Thanks for your quick reply. I will try to upstream a patch later. Thanks, Matt At 2019-12-12 11:15:51, "Edison Ai \\(Arm Technology China\\) via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: >Hi Matt, > >Thanks very much for your mail. It looks like it is indeed a problem here. >Can you upstream a patch to help to fix them directly? > >Thanks, >Edison > >-----Original Message----- >From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M >Sent: Thursday, December 12, 2019 9:43 AM >To: tf-m(a)lists.trustedfirmware.org >Subject: [TF-M] Secure storage and Internal trusted storage code logic check > >Hi TFM Secure storage & Internal trusted storage experts, > > > It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. > There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: > > > for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i); > } > This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. > If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START > is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. > Should it be the following logic? > > > for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); > } > It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. > > > Please help to check. > > >Thanks. >Matt. > >-- >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

4 years, 10 months

1
0
0 0

Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

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

4 years, 10 months

1
0
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by Edison Ai (Arm Technology China)

Hi Matt, Thanks very much for your mail. It looks like it is indeed a problem here. Can you upstream a patch to help to fix them directly? Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Thursday, December 12, 2019 9:43 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Secure storage and Internal trusted storage code logic check Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

Secure storage and Internal trusted storage code logic check

by lg

Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt.

4 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M