The current manifest building and loading process consumes amount of time and memory resources for some workloads which has many direct and indirect dependencies including dynamic libraries, configuration files and data files. the original design of it may become one of bottleneck for complex workloads along with larger EPC available to use, the current design shown in Fig.1
Fig.1 Original manifest processing
There are several potential problems
1) The generated ...manifest.sgx file replicates the ...manifest.template and ...manifest files
2) The size of generated ...manifest.sgx file is significantly larger than the ...manifest.template and ...manifest files
3) The key of trusted files in ...manfest.sgx occupied a lot of space
4) The generated ...manifest.sgx file hardly is human readable due to those inserted associative checksums with trusted files
5) The ...sig signature file don't bind to user configured ...manifest.template file
6) The ...manifest.template will confuse end users, because conventionally, it is a template for user configured file not configuration file itself.
7) The Pal load needs to consume highly indeterministic initial EPC memory resource to load & parse the manifest itself as mentioned in issue #2680
8) There are some placeholders where building tool needs to fill it up that is not fully deterministic.
The proposed solution shown in Fig. 2
Fig.2 Proposed manifest processing
The solution addressed those problems in question.
1) Move ...manifest.template file out of building process, the end user should provide ...manifest file instead of template file to reduce replication and avoid confusion, a assistant tool may help end user to configure it.
2) ...manifest.sgx file contains checksum for trusted files only to reduce replication, the signature file takes care of both ...manifest.sgx and ...manifest files
3) In ...manifest.sgx file, it removes the key of file and its checksum, instead, it is a serialized blob file that contains a array of tuple of file and its checksum as [(file, checksum)...] to largely reduce the size of it to load into initial EPC memory space
4) Obsolete the Pal runtime parsing process for ...manifest.sgx file as it already got parsed and saved as a blob in building process. it will reduce the loading time while saving EPC space.
5) Reduce the complexity of manifest processing
Description of the problem
The current manifest building and loading process consumes amount of time and memory resources for some workloads which has many direct and indirect dependencies including dynamic libraries, configuration files and data files. the original design of it may become one of bottleneck for complex workloads along with larger EPC available to use, the current design shown in Fig.1
Fig.1 Original manifest processing
There are several potential problems 1) The generated
...manifest.sgx
file replicates the...manifest.template
and...manifest
files 2) The size of generated...manifest.sgx
file is significantly larger than the...manifest.template
and...manifest
files 3) The key of trusted files in...manfest.sgx
occupied a lot of space 4) The generated...manifest.sgx
file hardly is human readable due to those inserted associative checksums with trusted files 5) The...sig
signature file don't bind to user configured...manifest.template
file 6) The...manifest.template
will confuse end users, because conventionally, it is a template for user configured file not configuration file itself. 7) The Pal load needs to consume highly indeterministic initial EPC memory resource to load & parse the manifest itself as mentioned in issue #26808) There are some placeholders where building tool needs to fill it up that is not fully deterministic.
The proposed solution shown in Fig. 2
Fig.2 Proposed manifest processing
The solution addressed those problems in question. 1) Move
...manifest.template
file out of building process, the end user should provide...manifest
file instead of template file to reduce replication and avoid confusion, a assistant tool may help end user to configure it. 2)...manifest.sgx
file contains checksum for trusted files only to reduce replication, the signature file takes care of both...manifest.sgx
and...manifest
files 3) In...manifest.sgx
file, it removes the key of file and its checksum, instead, it is a serialized blob file that contains a array of tuple of file and its checksum as[(file, checksum)...]
to largely reduce the size of it to load into initial EPC memory space 4) Obsolete the Pal runtime parsing process for...manifest.sgx
file as it already got parsed and saved as a blob in building process. it will reduce the loading time while saving EPC space. 5) Reduce the complexity of manifest processing