Visible to Intel only — GUID: GUID-8A624EEA-ED91-4303-8D3C-96AD8058E5AE
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-8A624EEA-ED91-4303-8D3C-96AD8058E5AE
Abandoned Sessions
Intel® DAL allows for a limited number of trusted applications and sessions that can be installed or created by the virtual machine (VM). In some cases, client service resources can be occupied and never released due to:
- Denial of service attack
- Application entering an infinite loop and therefore not closing or removing the sessions or trusted applications.
- Application crashing and therefore not closing or removing the sessions or trusted applications.
- A misuse of the client service API,e.g., not calling the CloseSession API when finishing using a session.
In such cases, the application is preventing other applications from using other sessions, due to the Max Sessions capacity limit. Therefore, the client service tries to detect whether an application has crashed or exited without releasing its resources so that it can perform cleanup, release the session handle and remove the abandoned sessions from the VM if needed.
To enable the client service to do this, it stores the application information [Process ID + Creation Timestamp] when the application is initialized. This allows the identification of crashed applications only and not modules within an application(like a plugin in a browser), unless it runs as a separate process.
Whenever an application calls one of the following APIs, the client service performs an abandoned session cleanup:
- JHI_Install2
- JHI_CreateSession
- JHI_Uninstall
- JHI_GetAppletProperty (in case the trusted application was not loaded in the VM)
Note: Applications should not rely on this cleanup mechanism and must call JHI_CloseSession with each session handle that they have when they are finished with the session handle.