Requirements and Specifications
As far as requirements are concerned, SystemReady compliance is important but many markets have additional requirements on firmware:
NIST 800 series in many areas but particularly for consumer (cf. USA Executive order on cybersecurity and NIST 8259 and 8259A)
One of the goals of Trusted Substrate is to implement technologies in various projects so that creating WP.29 or NIST 800 compliant products is as simple and fast as possible.
On the implementation quality and performance side, there are a number of specifications or recommendations that are considered:
PSA product certification level 3 readiness
Some markets such as automotive have boot time constraints that result in firmware performance constraints
Another goal of Trusted Substrate is to implement technologies in various firmware and non firmware projects to reach those performance and quality requirements.
On the feature/behavior side, some operating system or hypervisor level services may rely on firmware or secure firmware facilities such as
Parsec support
Global Platform compliant TEE interface
Device assignment
Other candidates under consideration
Microsoft OpenEnclave as a richer Application - TEE application framework
FIDO device onboarding and provisioning
GSA device lifecycle management (standardization of keys/secrets/certification/fuses provisioning at manufacturing time)
So it is a goal of the Trusted Substrate to implement technologies in various firmware and non firmware projects to have present operating systems or hypervisors with consistent behavior.
Combining all those requirements, Trusted Substrate ambition is to enable industrial grade off-the-shelf operating systems and hypervisors to run as is on compliant platforms and greatly augment supported platforms for vertical market targeted distributions such as Oniro, Civil Infrastructure Platform, Automotive Grade Linux, OpenIL, Scientific Linux and its derivatives as well as LEDGE Reference Platform and other commercial versions.
All platform independent and Arm specifications related recipes will be folded in to meta-arm layer, while market specific recipes (WP.29 or others) will be maintained in meta-trustedsubstrate.
Trusted Substrate-IR (yet to be formally defined)
IR stands for "IoT Ready". The definition of IoT is very board and can apply to single core or tens of cores platforms with multiple 10Gbps ethernet ports.
"IoT Ready" platforms may have strict boot time, security, safety readiness requirements.
ARM
SystemReady-IR (see appropriate section in document)
Trusted Base System Architecture (optional)
Base Boot Security Requirement (optional in SystemReady-IR)
Guidance and RFP readiness
Global Platform
UEFI
Trusted Substrate-ES (yet to be formally defined)
ES stands for Embedded Server. It differs from SR (Server Ready) with less hardware requirements. Operationally it may though require more security protections as ES will be exposed out of data centers.
ES is more applicable to Telecom edge for instance while IR (see above) is more applicable to industrial/automotive.
SystemReady-ES (see appropriate section in document)
optional: Trusted Base System Architecture
Base Boot Requirement (see appropriate section in document)
See SBBR recipe
Base Boot Security Requirement (optional in SystemReady-ES)
optional TCG (measured Boot
Software Updates for Internet of Things (suit): cross-cortex-A,M,R firmware update metadata.
Guiding documents (RFP readiness)
Trusted Substrate visible Interfaces
UEFI : Boot and OTA
PSA - Firmware Framework A: memory allocation services, update services...
SCMI
PSCI
optional Platform Abstract Security (Pasec) backends such as fimwareTPM
Trusted Substrate components (all flavors)
Components
SCMI server
firmwareTPM
Services