ld.so assertion failure when using raw-dylib on Linux

[jethrogb]

I tried the raw-dylib feature in fortanix/rust-sgx#804 but unfortunately I couldn't get it to work. I'm getting this error when doing cargo run -p fortanix-sgx-tools --bin ftxsgx-runner.

Inconsistency detected by ld.so: rtld.c: 2013: dl_main: Assertion `GL(dl_rtld_map).l_prev->l_next == GL(dl_rtld_map).l_next' failed!

This is on Ubuntu 24.04 with libc 2.39-0ubuntu8.5. rustc 1.89.0-nightly (d4e1159 2025-06-21).

There are no major differences in objdump -P (just the ordering of DT_NEEDED entries is different, but I don't think that should matter?). There is a small difference in objdump -T:

--- objdump-T.fake-vdso
+++ objdump-T.raw-dylib
-0000000000000000  w   DF *UND*	0000000000000000  Base        __vdso_sgx_enter_enclave
+0000000000000000  w   D  *UND*	0000000000000000  Base        __vdso_sgx_enter_enclave

I don't know that this is related to the assertion failure, but it's a bit surprising to me the F flag isn't getting set using the new method. I'm using extern { fn ... } in addition to using .type ..., function in assembly.

[mati865]

Does it also easily reproduce on linux-gnu triples?

[jethrogb]

Yes this is on Linux

[jethrogb]

I manually edited the final ELF (not the generated .so) to set the function type, that didn't help.

[bjorn3]

Oh there's a generated .so? Is that available in target/ somewhere?

I don't remember if we create it at compile or at link time. In the former case it would be bundled into the rlib (possibly wrapped in an object file that is copied out at link time), in the later case it ends up in /tmp and is removed after linking. You can try RUSTFLAGS="-Csave-temp --print link-args" to hopefully prevent it from getting deleted and to see where it ends up.

[bjorn3]

Note to self: Check that we correctly write the symbol size for statics. It is part of the ABI with PIE executables. I don't think this is relevant for this issue.

[jethrogb]

Here's the generated .so: libb6iem7bv99ccfj06ntbzl7te2.so.zip (remove the .zip extension, required for GitHub upload).

I don't immediately see any major differences with the stub .so we were previously using, besides the symbol type.

[mati865]

I used Wild linker to debug it and this is what it tells about current raw-dylib-elf:

❯ ./run-with wild --sym-info __vdso_sgx_enter_enclave
Global name `__vdso_sgx_enter_enclave` refers to: Some(SymbolId(114906))
Definitions / references with name `__vdso_sgx_enter_enclave`:
  Global NoType: symbol_id=114906 -> 114906 DYNAMIC res=[]
    #1 in File #66565 (260/5) /home/mateusz/tmp/vdso-wild/tmp/rustcgejXRG/raw-dylibs/libb6iem7bv99ccfj06ntbzl7te2.so (LOADED)

Compared to asm version:

❯ ./run-with wild --sym-info __vdso_sgx_enter_enclave
Global name `__vdso_sgx_enter_enclave` refers to: Some(SymbolId(208))
Definitions / references with name `__vdso_sgx_enter_enclave`:
  Global Func: symbol_id=208 -> 208 DYNAMIC | FUNCTION res=[]
    #4 in File #515 (2/3) /home/mateusz/tmp/vdso-wild-asm/home/mateusz/Projects/rust-sgx/target/debug/build/enclave-runner-daa0def0986fc5b2/out/libfortanix_enclave_runner_fake_vdso.so (NOT LOADED)

Indeed, FUNCTION is missing but patching it in rustc doesn't solve the problem.

There is more: in asm version, the library is marked as NOT LOADED. However, even with replicated .text section flags, it's still getting loaded.

Then after a bit digging in Wild's code I've found the culprit.
This is the command line for linking asm version:

...
--as-needed \
-Bdynamic \
-lfortanix_enclave_runner_fake_vdso \
-Bstatic \
...

while for raw-dylib version this goes:

...
-Bdynamic \
...
--no-as-needed \
-l:libb6iem7bv99ccfj06ntbzl7te2.so \
--as-needed \

Yeah, removing --no-as-needed right in front of -l:libb6iem7bv99ccfj06ntbzl7te2.so fixes the binary, even with the nightly version (without patches to raw-dylib).

[jethrogb]

Curious. If you look at the removed comment in tcs.rs , we actually want --as-needed, because otherwise the linker discards the whole library since we only have weak linkage.

[jethrogb]

@mati865 I've repeated your test, the resulting binary doesn't have a DT_NEEDED entry for the VDSO.

[usamoi]

This seems to be related to the order of linking. Regardless of whether it's a stub generated by raw-dylib or a stub from the repo, if -l:linux-vdso.so.1 is before -lc in the linker arguments, the executable works. Otherwise, it doesn't.

For a working executable, the contents of the dynamic section are as follows:

  Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [linux-vdso.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

For a non-working executable, the contents of the dynamic section are as follows:

0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
0x0000000000000001 (NEEDED)             Shared library: [linux-vdso.so.1]

I read rtld.c and found how the assertion fails:

1. initially, it maintains the linked list "", "/lib64/ld-linux-x86-64.so.2", "linux-vdso.so.1"
2. it reads the binary, and gets the search list "", "/usr/lib/libgcc_s.so.1", "/usr/lib/libc.so.6", "/lib64/ld-linux-x86-64.so.2", "linux-vdso.so.1"
3. the linked list becomes "", "/lib64/ld-linux-x86-64.so.2", "linux-vdso.so.1", "/usr/lib/libgcc_s.so.1", "/usr/lib/libc.so.6"
4. "/lib64/ld-linux-x86-64.so.2" is removed from the linked list
5. "/lib64/ld-linux-x86-64.so.2" is inserted into the linked list, after "/usr/lib/libc.so.6", and before "/usr/lib/libc.so.6", in order to respect the order of search list, without considering the presence of "linux-vdso.so.1"
6. assertion fails

ld did not take into account that "linux-vdso.so.1" could be in the search list.

1. Is this a bug of ld?
2. Is this use case unusual?
3. Is there a rule requiring that if "linux-vdso.so.1" is in the search list, it must be before "/lib64/ld-linux-x86-64.so.2"?

[mati865]

@mati865 I've repeated your test, the resulting binary doesn't have a DT_NEEDED entry for the VDSO.

Yeah, it's the same as with asm variant, where the resulting binary also doesn't have DT_NEEDED linux-vdso.so.1. Tested with both ld.bfd and Wild.

Is this use case unusual?

I think so? It's hard to find any concrete information regarding this issue, I imagine there would be more searchable information if it was at least somewhat common.