Visible to Intel only — GUID: GUID-B7E0E744-1E61-44AD-8AFF-98EA4D61E7AB
For API Level 1 - Intel® ME 7.x - Sandy Bridge
For API Level 1.1 - Intel® ME 8.x lite - Sandy Bridge
For API Level 2 - Intel® ME 8.0 - Ivy Bridge
For API Level 3 - Intel® ME 8.1 - Ivy Bridge
For API Level 3 - SEC1.0, SEC1.1, SEC1.2, SEC2.0
For API Level 4 - Intel® ME 9.5, Intel ME 9.5.55 - Haswell
For API Level 4 - Intel® ME 9.1, Intel ME 9.1.35 - Haswell
For API Level 5 - Intel® ME 10.0.0 - Haswell
For API Level 6 - Intel® ME 10.0.20 - Broadwell
For API Level 7 - ME 11.0 - Skylake_LP and Skylake_H
For API Level 8 - TXE3.0 - Broxton, ME 11.5/11.8 - Kabylake_LP, Kabylake_H
For API Level 9 - Intel® ME 12.0 - Cannon Lake
Trusted Application Validation Guidelines
Validating the Manifest
Memory and Performance
Error Handling and Recovery
Functional Validation and Multi-Instance Support
Pack and DALP Generation and Validation
Host-Side Software Validation Guidelines
Trusted Application Management Flows
Error Handling and Recovery Flows
Multi-Instance and Interoperability Testing of Trusted Application Management
General and Platform-Related Events
End-to-End and Setup Validation Guidelines
Cross Trusted Application Interoperability Functional Testing
Creating a New Project
Importing an Existing Project
Converting an Existing Project
Building and Packaging Your Project and Running in Emulated Environment
Running Your Project
Running and Testing on Emulation and on Silicon
Debugging Trusted Applications
Preparing and Submitting Your Project for Signing
Signing an Applet
Signing New Versions
Visible to Intel only — GUID: GUID-B7E0E744-1E61-44AD-8AFF-98EA4D61E7AB
Validating the Manifest
The manifest has various roles, but it is important to understand it has major impact on the functionality of the trusted application and on the setups in which it will load and function. The manifest is used for limiting the installation of the trusted application to specific setups, for enabling various features or even for limiting the heap size allocated for the trusted application.
So how do we validate the manifest file and who should create it?
There are two stages to the manifest validation:
- Pre-production
- Post-production
First we need to check which manifest values are being used by development team, and which are used in validation setups.
Note that some of those are only relevant for pre-production setups. In production we cannot change the values, since the trusted application is signed for production.
So, during the pre-production validation, we need to cover the following:
- Functional limitation - Heap-Size, ID, flash-quota, all events related support (for both post and register), etc.
- Installation limitations - Minimal firmware version, trusted application and security versions, platform, SKU/CPU limitations, feature set, IPT restrictions, etc.
On the production signed trusted application validation, we should cover the following
- Ensure that the signed trusted application has correct manifest values as defined in the signing request and values which were used during pre-production validation. This can be done by various tools provided in engineering releases or the SDK in Intel® DAL.
- Run manifest-related tests on production setups (e.g. checking that the trusted application is installed on the relevant setups, and doesn't where it should be restricted) and general functional flows (e.g., Intel® Enhanced Privacy ID (Intel® EPID) provisioning has many differences in production setup due to various certificate differences).
The production validation step is very important and usually must be planned in advance, since we need to order the relevant hardware parts in advance.