Intel® Dynamic Application Loader (Intel® DAL) Developer Guide
ID
773482
Date
3/24/2023
Public
Visible to Intel only — GUID: GUID-0C9DF02E-AE89-460B-B178-2D9CFAF11EF0
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
API Usage and Generation Alignment
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-0C9DF02E-AE89-460B-B178-2D9CFAF11EF0
Trusted Application Validation Guidelines
This section covers all validation aspects of the trusted application code and functionality. In addition it covers different aspects of converting the code into the final pack and DALP formats. This includes the manifest values used for validating the trusted application, since in the production (signed) version the manifest will be generated by the team responsible on processing the signing request.
API Usage and Generation Alignment
The following areas should be taken into account when validating the trusted application code:
- Event handling classes implementation - All of the event-driven features (such as Timers, Trusted application-Event, Capability Licensing Service, etc.) use callback functions which are implemented inside the code of the trusted application. So the following should be covered:
- There are several ways to implement those, but only portions of those are really supported by Intel® DAL infrastructure (due to design related issues). Validating this is important to ensure data sent or received is actually valid .
- Must ensure those callbacks will not be stuck in a dead-lock.
- If a timeout value is defined in the manifest it will impact also the execution of all event-callbacks. You should review such cases and understand what is the impact on the trusted application (the VM will end the execution of the session) and on the general flow.
- Trusted application interface and supported commands - All trusted applications extend the Intel trusted application interface. The interface exposes various commands that should and can be implemented. Therefore the following areas should be reviewed and tested:
- Which of the APIs are actually implemented? Some of the methods can exercise code while opening or closing a session to the trusted application. These areas are very important, especially when thinking of a multi-instance environment.
- Reviewing which of the parameters are actually used and for what purposes are questions that should be asked by the validation team.
- The way in which we establish trust between host side software and the trusted application must be validated and reviewed by both validation team and security reviewers of the trusted application. Can any application in the host communicate with our trusted application?
- Which packages does the trusted application use and why?
- Session management - As mentioned above, some commands can be implemented and executed during session establishment or teardown. Areas that should be covered:
- Note the difference between shared and non-shared sessions. In shared session we actually have in practice only one real session of a trusted application in the firmware.
- Test what happens if sessions aren't closed properly or closed while other sessions are still in progress should also be covered.
- Which APIs are being used upon session creation and closure? Note that some operations there are restricted (e.g. setResponse()).
- Storing data and state - In general trusted applications should not be seen as processes that store state. Trusted applications usually offload the part of the code that should be executed in a secured environment. Trusted applications will lose all data and state due to various reasons (such as power flows) so if some data should be stored cross sessions or power flows, the relevant guidelines described above should be used.
- If the trusted application uses Pbind keys (Platform bind keys) those may also be impacted by a Return To Factory Defaults (RTFD) operation- see Platform Binding Key (Pbind).
- If the trusted application is using the flash-storage APIs you need to test and review what happens in cases of Clear-CMOS or TCB recovery.
- Reviewing the list of APIs used - As part of the tools provided in the SDK or engineering releases, you can easily list the APIs used by the trusted application. When reviewing the APIs you should consider the following:
- List of restricted or deprecated APIs (e.g. due to known bugs or general restrictions)
- APIs which need special manifest enablement (e.g. FlashStorage)
- The generation of the API used. e.g. using events-based APIs (Timers, trusted application-Events), WYSIWYS and more are not allowed on Intel® Management Engine (Intel® ME) 8.x-Lite machines (CPT based platforms with Intel ME 8 firmware) or on Intel ME 7.x machines.
- Note: This might have major impact on the ability to port your trusted application across platforms and generations.
- Infinite loops and timeouts - It is critical to ensure that trusted application cannot be stuck in some infinite loop. In addition, it is recommended to enforce a max limit for request handling by the trusted application in milliseconds. Note: The same timeout value is used for both invokeCommand and any event-based callback execution.
- General review of trusted application code - Reviewing the trusted application's code can be done in various stages and by various members and teams. It can and should be covered in code-reviews, SDL reviews and even by white-box testing. When reviewed the following should be take into account:
- Code size - As mentioned in the guidelines the size does matter, and if in future generations the same code will be used, it will reduce refactoring and therefore additional reviews
- Functional and Security review - you'll be surprised to see how many comments can be raised by various team members on a simple short section of code.
- Memory consumption - Reviewing when and where we allocate memory is very important.
- Resource and API usage model - Some of the APIs are limited to one trusted application at a time (e.g. WYS image rendering) while other consume lots of the platforms resources (e.g. RSA key-generation). Such areas should be carefully reviewed and we should limit our usage in those. In addition ensuring that our trusted application has limited impact on other trusted applications is an additional aspect which should be taken into account.