Hooks for platforms to handle SMCs which are not supported by the TSPD

[vwadekar]

There will be scenarios wherein platforms might want to use the TSPD but add some extra SMCs to the mix. The TSPD might not have support for these SMCs, which although fall in the TOS SMC aperture are specific to secure SO vendors.

For such scenarios, does it make sense to have a platform callback to allow handling of such custom SMCs? This would mean that secure OS vendors can reuse TSPD and also have their support plugged in, instead of writing a new SPD which is 90% same as TSPD.

[danh-arm]

The TSPD in its current form is closely coupled to the TSP provided - it is not intended to be used with other types of SP. If another SP wishes to handle extra SMCs, then the TSPD should be replaced with another SPD that is coupled with that other SP.

It is difficult for us provide reference SPD implementation(s) that cater for all types of SP since the interaction models vary considerably between SPs. Although the SPD you need might be 90% the same as the TSPD, we don't know which 90% is the same. We are willing to host separate SPDs that are coupled with specific SPs.

As we learn more about the different types of SPs out there, there may be opportunities to provide reference SPD(s) that cater for multiple SPs with similar interaction models. However, we don't have the visibility or knowledge to be able to do that currently.

[vwadekar]

Right now, if we can provide flexibility to include platform specific function IDs in tsp.h, then TSPD can mature into supporting multiple SPs out there. If you are willing, then with the following modification, platforms wont have to override the TSPD.

e.g. tsp.h: add a carveout in the function ID space for NS->S requests (standard and fast can reside in this carveout) and another carveout for EL1-S->EL3 requests.

tspd_main.c: default case can call a platform handler to check if the platform supports the SMC. If it returns error then return SMC_UNK. A weak implementation which always returns SMC_UNK can be added to platform_helpers.S.

Thoughts?

[danh-arm]

Although we could make modifications to the TSPD to make it easier to integrate into your specific SP+platform environment, these would not necessarily be appropriate for other SPs. Without having access to partner SP(D) implementations, this is not an area we want to get into. There is too much variability across TEE implementations

A more likely route to achieving standardized SPD implementation(s) is for partners to submit their own SPD implementations to the project. We would welcome your contribution in this here. Once a quorum of SPD implementations became available, the common elements could be abstracted out into common SPD code.

In terms of your specific suggestion, I agree that it would be good for a common SPD SMC handler to call out into platform-specific SMC handlers, although "platform" in this sense could be the TEE, the SoC or the board. However, I don't see the value of carving out the function ID space to separate NS->S SMCs and S-EL1->EL3 SMCs.

[athoelke]

The currently design philosophy in the Trusted Firmware code is that the TSPD and TSP are "example/demonstration/test code", the FVP port is a "reference port code" and the rest is intended to be "production code".

As Dan said, there is enough variation amongst the existing Trusted OS software solutions (both those that are provided by the SoC vendors and the portable commercial & OSS ones) that it would be impossible to provide a single (or even just 2 or 3) SPD which can support them all. ARM does not (at this point) want to specify/standardize the EL3/Secure-EL1 interface and generate a large amount of additional work for these OS developers to port to ARMv8 and result in forking their OS for use in ARMv7 or ARMv8 systems. Instead we expect the Trusted OS developers to provide a specific SPD for building into BL3-1 that understands the capability and interfaces to their Trusted OS in Secure-EL1.

Your proposal effectively promotes the TSPD to "production code" and all of its interfaces have to be managed and documented as part of the supported Trusted Firmware interfaces to Secure-EL1. This code is not ready for that change, and I expect that if we considered the wider requirement properly (providing a common, configurable SPD) we might want to refactor things in a different or more extensive way than that suggested here.

ARM is open to going in that direction, but we would need to take other Trusted OS's and their SPDs into consideration when doing so.

[vwadekar]

I understand Andrew. FWIW, we have gone ahead and added our own SPD. We can go ahead and push our SPD to the repository in the future.

Closing.