Visible to Intel only — GUID: GUID-BDBB579F-B971-4F8E-897B-9D20F7CD4210
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-BDBB579F-B971-4F8E-897B-9D20F7CD4210
Trusted Application Management Flows
The second and very important part of the validation effort should be directed to the validation of the host-side application which manages and communicates with your trusted application. Below there are several areas that should be taken into account and covered in your validation:
Install/Uninstall - It is quite clear that we should ensure that our trusted application can be loaded and unloaded from the system. But we need to extend our scope and ensure that we cover the following:
- Following the installation diagram while using the DALP package to be used in our production setup. This is important since there are different checks in the host-side level (by the Intel® DAL Host Interface Service) and others by the firmware itself.
- Covering all setups (hardware, firmware, software combinations) and in general the SKU matrix for the given generation.
- Trying to install/uninstall in different states of trusted application life cycle. As you know, you can't install a new version when a session is still opened to the previous version, and there are additional restrictions (mainly regarding the trusted application and security versions).
- When and how many times we load/unload our trusted application. Questions that should be covered during validation are whether that is necessary and what the impact is on performance.
- Reaching the maximal number of installed trusted applications in the system.
Session management - There are various ways to manage our trusted application instances, and they are driven by our usage model. Some aspects that should be covered are:
- Shared vs. non-shared sessions usage model
- Number of expected sessions that should be supported at a given time (e.g. WYSIWYS image rendering are restricted for one session at a given time)
- Sessions clean-up
- Recovery flows in case of trusted application crash, Intel DAL Host Interface Service reset, etc.
- Ensuring when and why are we opening/closing a session and the impact on our performance should be covered during validation
Event handling - In opposition to the first Intel DAL generation (Gen1 - Intel® Management Engine (Intel®ME) 7.x), in which the model was of client-server (the trusted application being the server), for Gen2 the trusted application can send data back to the host side by sending an event to which the host side must register in advance. In the validation scope, you should ensure that this is used only as a means to inform the host side that the trusted application has either received some event (which causes a state change) or some timeout has occurred. The host side should now use the regular 'SendAndRecieve' interface for passing or getting the data to/from the trusted application.
General data and status - The Intel DAL Host Interface Service exposes various APIs for querying the trusted application and platform. Ensure you are making correct usage of those.