Handling dynamically loaded libraries
This section describes how to make sure that the dynamically loaded libraries that are needed will be a part of the manifest file.
anjuna-compile-manifest will automatically identify the dynamic dependencies of a binary if the dependencies are mentioned in the headers of the binary. These dependencies and their hashes are automatically added to the manifest file.
As described earlier, if the dependency is not a part of the manifest, or its measurement is
different, the Anjuna Runtime will print a related warning to stderr.
Dependencies that are not a part of the manifest
In the case where the dynamically loaded library (path and file name) does not exist in the manifest
- an error of the following format will be printed to stderr:
[62995] mmap of code address range 0x80691a000-0x806a60000 blocked - /usr/lib/x86_64-linux-gnu/libc.so
To solve this problem, you can add the missing file to the
manifest template file under the entry trusted_libs.
For example:
trusted_libs:
- /usr/lunasa/lib/libCryptoki2.soDependencies with a different measurement
In the case where the path and file name match, but the measurement, or hash value, is different
- an error of the following format will be printed to stderr:
[62855] Failed to verify SHA-256 digest: digests mismatch [62855] Accessing file:/usr/lib/x86_64-linux-gnu/libc.so.6 is denied. (Permission denied.) This file is not trusted.
To solve this problem, determine if the library is indeed the correct library. If you trust the library with the new measurement, delete the manifest file and recompile it from the template (anjuna-compile-manifest or anjuna-sgxrun).