Hi,

Even though the cases sound complicated, but most of the cases can be handled by TFM implementation from framework level. The only exception is case 5 – users need to decide if they want an easy integration but not that real-time or stick to real-time and implement something customized (NSPE claims ISR, create a forwarding thread and so on).

Here are some comments that might help to answer some of the question marks, and feel free to comment back if there is something improper or incorrect from your view.

* For case1, as you commented, it can support multiple client access different secure services simultaneously; but if one same services are required by client or service dependency chain then it has to wait there. This the why some IDLE or yield processing mechanism are required. This should be applicable for most of the cases – generally we should not bind a real-time sensitive functionalities with security ones. * Case 2 can be covered by the updated mailbox agent design. It is users’ decision to use one agent cover multiple channels (or even protocols) or use multiple agents for better isolation. The former one can work under an overall SFN model in a remote-only design as mailbox agent can have the wait loop in its initialization function for handling incoming requests. * Case 3 just combines the case 1 and 2, but makes the SFN model for remote-only design not applicable as SPE would eventually launches NSPE and wait for incoming secure service call. * Case 4 does not have a real usage from my point of view, secure services typically cannot have strict real-time characteristics. For mailbox agents, it is running asynchronously so it can handle interrupt threaded signals sooner than classic partitions but this is not a strict real-time application. * Case 5 is mostly to handle the case that users have some classic real-time usages in NSPE. If so, loop in SPE mailbox agent won’t be applicable. Users can let NSPE to handle the interrupt for mailbox and ping SPE by a NS thread, or just have to wait longer in SPE until next scheduling back.

BTW: as we allow binding a user data in the updated mailbox agent API, handling messages for different protocols or channels are possible:

userdata1.protocol = &1ST_PROTOCOL; // Set protocol for session psa_call(params1, userdata1);

userdata2.protocol = &2ND_PROTOCOL; psa_call(params2, userdata2);

… while(psa_wait(ALL)) { get_userdata(&ud); ud.protocol(ud.parameters); // Call corresponding protocol dispatcher. }

BR

/Ken

From: Chris.Brand--- via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, June 27, 2023 8:07 AM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: Hybrid platforms discussion follow up.

Hi Anton,

Thanks for leading this. This seems like a good path forward for TF-M.

Looking at the use cases listed in slide 3 there, I’d say that Case 1 seems interesting (I can imagine one client wanting to use PS while another simultaneously uses crypto, for example) Case 2 feels like a logical extension of the existing multi-core support. The question in my mind is how many cores we expect to have while remaining within the target for TF-M. Given that cases 1 and 2 both make sense, the first option in case 3 also seems to make sense. Not sure about local clients communicating with local SPE but not via TZ, but maybe that makes case 3 an extension of case 2 rather than something new, and so easier to implement? I suspect that case 4 and 5 are both interesting, given TF-M’s target environment. It’s obviously tricky to support real time with both local and remote clients, but that would be a good feature to support. I find it difficult to imagine having multiple remote cores that aren’t able to use the same communication channels. I do expect different platforms to use different communication channels - we have that today with RSS and Corstone, but I don’t believe it’s as clean as it could be.

Chris

From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: June 26, 2023 2:31 AM To: Edward Yang via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [TF-M] Hybrid platforms discussion follow up.

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.

Hi,

On the last tech forum (June 22) we started discussion on multicore hybrid platforms. By this mail I’d like to follow up and continue offline analyses on new use-cases and requirements for TF-M design update.

The recorded session is available here: https://linaro-org.zoom.us/rec/share/yseF-mYwUTtHHPkQJQO6IEv72xCd0Lz1pQQecc2..., Passcode: 5s=Npv=w and slides: https://www.trustedfirmware.org/docs/tech_forum_20230622_Hybrid_platforms.pd...

The current plan is to take time, think on the use-cases and map them on requirements. With more thought and materials, we will have another session about September time to define our needs in the support of new type of platform.

Please share your thoughts in reply.

Thanks, Anton