Intel® Dynamic Application Loader (Intel® DAL) Developer Guide
ID
773482
Date
3/24/2023
Public
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
Memory Management
This page provides guidelines for managing memory in your applet. For details on the memory capabilities of the Intel® DAL environment, see Memory.
The following are some of the memory-related design considerations:
- The VM does not handle fragmentation in the memory. This means that allocating and de-allocating a large number of small sized memory chunks might lead to the situation where a memory request will not be honored because of the lack of a contiguous block of suitable size even though the amount of memory is available. Thus it is advisable to allocate larger needed chunks of memory first.
- In general, due to heap fragmentation, it is recommended to add ~40% to the estimated trusted application heap usage from the amount measured in profiling and use that larger value as a manifest parameter.
- For the above reason trying to allocate a large buffer (e.g. for encryption or transmission) may fail while allocating a number of smaller buffers, even with the same total size, may succeed.
- It is recommended to let the garbage collector handle the memory that you are not using, i.e., don't save, as members of the class, memory that you don't need to.
- When the applet runs out of memory, OutOfMemoryError should be thrown, to allow the applet to recover properly (i.e., to release unused memory). Note that there are cases when OutOfMemoryError should be thrown but there is not enough memory to allocate the error. If this happens, the session with the applet is terminated and the host application receives an APPLET_FATAL error.
Determining Actual Memory Requirements for a Trusted Application
The actual memory requirements for a trusted application can be reported while running the trusted application in the emulated environment. Here's how to do it:
- Edit the emulation configuration (.ini) file. This file, RP_AMT06.INI, is in the appropriate sub-folder under the DALsdk Installation directory, e.g. %DALsdk_root%\DALdic\Emulators\ME71\RP_AMT06.INI
- Edit the Intel DAL section to specify the location of the file where the emulator will log the required information, and set the Memory Profiling option MemProf to 1.