Allow symbols exported by libraries to be exported by libsgxlkl.so

[jhand2]

OE exports some symbols which are patched by the loader and oesign. To support this functionality, remove linker flags which prevents libsgxlkl.so from exporting symbols exported by OE libraries.

[davidchisnall]

I am not sure what this is meant to do. We should not be exporting any OE symbols to userspace.

[jhand2]

Basically loading/signing relies on fixing up some exported symbols. OE used to just read regular symbols, but this is brittle because if symbols are stripped then the enclave can no longer be signed/loaded. So now OE depends on symbols in the .dynsyms section. But the previous linker flags kept these symbols from being places in .dynsyms

This is the OE change that causes this issue to manifest: https://github.com/openenclave/openenclave/pull/3359

cc @anakrish

[davidchisnall]

I see, so OE is now going to require that we have a custom linker script? Exporting all symbols as dynamic is a completed unacceptable solution, because we need to hide most of our symbols from the userspace application that we load. Does OE provide a sample linker script that we can use as a base to export the necessary ones as dynamic?

A final version of this should not be merged until after lsds/sgx-lkl#818

[jhand2]

Is it acceptable to export all symbols in dynsyms which are exported from OE libraries?

[anakrish]

@davidchisnall

We should not be exporting any OE symbols to userspace.

Currently, the OE loader expects to be able to find the following symbols:

• _enclave_rva
• _relocrva - _reloc_size
• _tdata_rva
• _tdata_size
• _tdata_align
• _tbss_size
• _tbss_align
• _td_from_tcs_offset

Earlier we relied on regular symbols which was brittle. The loader would stop working if the enclave image was stripped. Now we rely on dynamic symbols.

We are considering other approaches too, but not in the near term:

• have the enclave parse the elf headers and figure out all the necessary information
• or use separate sections for this information

[jhand2]

@davidchisnall this only exports to dynsyms symbols that the .a file has explicitly exported (with __attribute__((visibility("default")))). I checked the resultant libsgxlkl.so and most OE symbols are not exported. Are there particular symbols you're concerned about that I can check for?

[wintersteiger]

@anakrish instead of relying on those symbols being present, couldn't we be a bit more conservative in the loader and simply skip patching those symbols if they are not present? There may be the odd place where we have to assume a 0 in place of an absent symbol, but I don't think there would be many such places.