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@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@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: Tuesday, February 12, 2019 9:39 AM To: tf-m@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@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m