The manifest has various roles, but it is important to understand it has major impact on the functionality of the trusted application and on the setups in which it will load and function. The manifest is used for limiting the installation of the trusted application to specific setups, for enabling various features or even for limiting the heap size allocated for the trusted application.
So how do we validate the manifest file and who should create it?
There are two stages to the manifest validation:
First we need to check which manifest values are being used by development team, and which are used in validation setups.
that some of those are only relevant for pre-production setups. In production we cannot change the values, since the trusted application is signed for production.
So, during the
we need to cover the following:
– Heap-Size, ID, flash-quota, all events related support (for both post and register), etc.
– Minimal firmware version, trusted application and security versions, platform, SKU/CPU limitations, feature set, IPT restrictions, etc.
production signed trusted application validation,
we should cover the following
Ensure that the signed trusted application has
correct manifest values
as defined in the signing request and values which were used during pre-production validation. This can be done by various tools provided in engineering releases or the SDK in Intel® DAL.
on production setups (e.g. checking that the trusted application is installed on the relevant setups, and doesn’t where it should be restricted) and general functional flows (e.g., Intel® Enhanced Privacy ID (Intel® EPID) provisioning has many differences in production setup due to various certificate differences).
The production validation step is very important and usually must be planned in advance, since we need to order the relevant hardware parts in advance.