Visible to Intel only — GUID: GUID-8A1B6ED4-70EC-4C1A-A95A-32DDC00449C2
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-8A1B6ED4-70EC-4C1A-A95A-32DDC00449C2
Memory
This page describes the memory capabilities of the Intel® Dynamic Application Loader (Intel® DAL) environment. For advice on how to manage memory in your applet, see the appropriate Guidelines page.
Intel DAL secure applications have memory and trusted application size requirements that are stricter than general purpose trusted applications. The VM implementation supports up to five sessions running simultaneously and limits the entire memory footprint available for trusted application code and heap.
There are two aspects of the memory footprint of a trusted application:
- The memory taken up by trusted application code and static memory allocation.
- The dynamic memory on the heap used by and for the trusted application during run-time.
Trusted application and heap memory are both consumed from the Intel DAL module memory which is currently limited to a total of 2 MB. This is the total memory available for all applets.
These two components are regarded and treated separately.
Non-volatile memory: This is the flash memory in the secure environment that is available for the applet to use as storage. In API level 7 and later, the maximum amount of flash memory available for storage by the applet is 5K. In earlier API levels, the amount is 256 bytes. It is recommended to store encrypted applet code and data on the hard disk, and store the encryption keys in the secure flash memory. The amount of NVM must be defined in the applet's manifest.
Trusted application writers should make the size of a trusted application and its memory signature as small as possible, for the following reasons:
- Before Intel signs the trusted application, it checks the code size and memory usage (declared in the applet's manifest). If the applet's code size is too large, or it uses too much memory, Intel may not agree to sign it.
- Intel DAL has a limited amount of memory, so it is possible that Intel DAL will not be able to run all the existing applets at the same time. Intel DAL uses a "first come first served" approach. If there is not enough memory available to run an applet, an Out Of Resource failure is generated during the applet's onInit command.
The Intel DAL trusted application VM has a garbage collection mechanism. Any memory allocations that are not referenced are eventually cleared by the garbage collector. Any global objects that still exist consume memory for the entire trusted application lifetime. Whenever possible, the global memory should be dereferenced or reused, as trusted application memory allocation is limited.