[Pal/lib] mbedTLS crypto adapter calls _DkRandomBitsRead() but is also linked into LibOS

[dimakuv]

Description of the problem

We have the "common library" that has a bunch of Standard C and utility functions. This library is a static archive called graphene-lib.a and is linked into both PAL binaries and the LibOS binary (libsysdb.so).

This "common library" includes the crypto code. In particular, it includes the minimal mbedTLS code and our Graphene convenience wrappers around it. These wrappers define and call _DkRandomBitsRead() as a callback to initialize the mbedTLS software PRNG.

But this is wrong from a design point of view: LibOS links against the common library and sees the calls to _DkRandomBitsRead(), which is an internal function of the PAL layer and should never be visible to LibOS. Fortunately, LibOS will not reference/use _DkRandomBitsRead() because this function is only called from mbedTLS wrappers. LibOS doesn't use these wrappers (in particular, the file mbedtls_adapter.o). So during the final linking step, when LibOS sources are linked against static graphene-lib.a, the linker notices that mbedTLS wrappers are not used and removes all that stuff. So in the end, the libsysdb.so library doesn't have any references to _DkRandomBitsRead().

I verified it by manually inspecting the symbols and relocations in the resulting libraries.

This is a pretty bad design decision though and should be fixed somehow.

This was found while working on #2367 .