Hi Ken, Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution?
Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good?
Regards, Jun
On 10/19/21, 00:23, "TF-M on behalf of tf-m-request@lists.trustedfirmware.org" <tf-m-bounces@lists.trustedfirmware.org on behalf of tf-m-request@lists.trustedfirmware.org> wrote:
Send TF-M mailing list submissions to tf-m@lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/tf-m or, via email, send a message with subject or body 'help' to tf-m-request@lists.trustedfirmware.org
You can reach the person managing the list at tf-m-owner@lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..."
Today's Topics:
1. Re: Sending events from TF-M to non-secure world? (Ken Liu) 2. Inline asm syntax unified and symbol reference in IAR toolchain (Ken Liu)
----------------------------------------------------------------------
Message: 1 Date: Tue, 19 Oct 2021 02:06:35 +0000 From: Ken Liu Ken.Liu@arm.com To: "tf-m@lists.trustedfirmware.org" tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Sending events from TF-M to non-secure world? Message-ID: DB9PR08MB67613655A2ACA207C751C791F5BD9@DB9PR08MB6761.eurprd08.prod.outlook.com
Content-Type: text/plain; charset="utf-8"
Hi Jun,
Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels.
Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns.
If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks.
The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details?
BR
/Ken
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 12:20 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Sending events from TF-M to non-secure world?
Hi,
Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way.
Appreciate any comments or suggestions!
Jun
Intel Corporation @ SC, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff8754e/attachment-0001.htm
Hi Jun,
To trigger an interrupt by software, Register 'STIR' may help you.
The scenario you are describing is a practical use case hence it makes sense to think more about it.
The scenarios you are describing is more related to the programming model - As the SPE is working more like a library, the NS caller polling the status of secure services by service interfaces and updating local presenting are more straight (and simple).
And if you have involved a callback/event-based programming model into your secure service already (3rd party provided such a library, e.g.), you'll have to invent some mechanism to interactive with NS. From the Firmware Framework - M perspective, the peripheral is private to a partition, you can treat shared peripheral/memory as private resources to this partition, claim it in the manifest, and use it to communicate with NS. This shared peripheral (Aka MMIO in the specification) is private, it cannot be shared with other partitions.
More comments?
BR.
/Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 10:42 PM To: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Sending events from TF-M to non-secure world?
Hi Ken, Thanks for the nice suggestions! I was thinking of using an interrupt from TF-M to NS world as well but that needs some hardware support, which should be fine since I'm still designing the device. Maybe there is a software interrupt solution?
Our application needs to put a biometric service inside TF-M and its enrollment process needs to send out some intermediate events to give the user some feedbacks. This is why I'm asking this question. I think TF-M can use an input buffer from NS world to store the new events and notify the NS world with the interrupt to fetch the new events. Sounds good?
Regards, Jun
On 10/19/21, 00:23, "TF-M on behalf of tf-m-request@lists.trustedfirmware.org" <tf-m-bounces@lists.trustedfirmware.org on behalf of tf-m-request@lists.trustedfirmware.org> wrote:
Send TF-M mailing list submissions to tf-m@lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.trustedfirmware.org/mailman/listinfo/tf-m or, via email, send a message with subject or body 'help' to tf-m-request@lists.trustedfirmware.org
You can reach the person managing the list at tf-m-owner@lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..."
Today's Topics:
1. Re: Sending events from TF-M to non-secure world? (Ken Liu) 2. Inline asm syntax unified and symbol reference in IAR toolchain (Ken Liu)
----------------------------------------------------------------------
Message: 1 Date: Tue, 19 Oct 2021 02:06:35 +0000 From: Ken Liu Ken.Liu@arm.com To: "tf-m@lists.trustedfirmware.org" tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Sending events from TF-M to non-secure world? Message-ID: DB9PR08MB67613655A2ACA207C751C791F5BD9@DB9PR08MB6761.eurprd08.prod.outlook.com
Content-Type: text/plain; charset="utf-8"
Hi Jun,
Basically, the service accessing model is a client-service model, hence the service won't call back to the client which makes the client a 'service'. Service can get client info by passed-in parameters and other SPM controlled channels.
Assuming you are using a Trustzone based hardware, the hardware provides the capability that calling back to NSPE, but it is not encouraged inside TF-M because it breaks the simplified model proposed by FF-M and difficulties the secure threat analysis - a simple case is that the secure context is blocked because it is waiting for NS returns.
If you do need to perform such operations, implement an interrupt based asynchronous mechanism is safer than software callbacks.
The most queried requirement we have met is someone querying if the execution can be delivered back to NSPE when secure IDLE is going to happen. Not sure if you are facing the similar, is it okay to share more details?
BR
/Ken
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Li, Jun R via TF-M Sent: Tuesday, October 19, 2021 12:20 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Sending events from TF-M to non-secure world?
Hi,
Anyone has idea how a service inside a secure partition can send out some events to the non-secure world? Does callback still work over IPC? It seems non-secure world can connect to a SP but not easy to do the other way.
Appreciate any comments or suggestions!
Jun
Intel Corporation @ SC, CA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.trustedfirmware.org/pipermail/tf-m/attachments/20211019/1ff8754e/attachment-0001.htm
tf-m@lists.trustedfirmware.org
-
Ken Liu -
Li, Jun R