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.

The anjuna-compile-manifest will automatically identify the dynamic dependencies of a binary if the dependencies are mentioned in the headers of the binary. In such a case, it will automatically add these dependencies (and so on), and their hashes 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 the standard error.

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 the standard error:

[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.so

Dependencies 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 the standard error:

[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).