Visible to Intel only — GUID: GUID-37C418FE-C958-42E0-AFC4-79AE4C1E58CF
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-37C418FE-C958-42E0-AFC4-79AE4C1E58CF
Error Handling and Recovery
One of the main aspects of trusted application validation is the negative validation of both the functional side and management side:
- Informative error reports - trusted application code should handle all possible errors that might occur due to invalid usage of the trusted application. In addition it should return some usable errors to the host-side for further error handling. The correct way to do so is via the relevant methods for error passing . Using different errors and values for various cases and states is recommended mostly since the debugging capabilities in production setups are very limited!
- Handling exceptions - Besides the exceptions, which are defined in the relevant APIs, additional run-time exceptions might occur. These should be taken into account during reviews and validation (e.g. nullPointerException or ArrayOutOfBoundsException). In addition, verifying that call-back functions handle all exceptions is also recommended, since an exception there will not be caught by the trusted application if it is thrown from the scope of the call-back.
Validation needs to cover the difference between what is returned by the trusted application versus error messages from the VM.