Loading external rlib raises Unsupported dynamic entry

[gerritsangel]

Loading external rlib raises Unsupported dynamic entry

[jethrogb]

If you want to set the compilation flags on the top level crate you can just use cargo rustc.

[gerritsangel]

Thanks for the reply! My project layout is this:

.
├── app
│   ├── src
│   │   └── lib.rs
│   └── Cargo.toml
├── enclave
│   ├── src
│   │   └── main.rs
│   └── Cargo.toml
├── Cargo.lock
└── Cargo.toml

The app/src/lib.rs looks like this:

pub fn foo() -> i32 {
    5
}

If I now run cargo rustc -p app -- -Cpasses=sancov-module -Cllvm-args=-sanitizer-coverage-level=1 -Cllvm-args=-sanitizer-coverage-trace-pc-guard, it creates the libapp.rlib and when checking the disassembly of the object file in the incremental folder, it correctly instruments it:

Disassembly of section .text._ZN3app3foo17h0966669265df2a47E:

0000000000000000 <_ZN3app3foo17h0966669265df2a47E>:
   0:	50                   	push   %rax
   1:	48 8d 3d 00 00 00 00 	lea    0x0(%rip),%rdi        # 8 <_ZN3app3foo17h0966669265df2a47E+0x8>
   8:	e8 00 00 00 00       	call   d <_ZN3app3foo17h0966669265df2a47E+0xd>
   d:	b8 05 00 00 00       	mov    $0x5,%eax
  12:	59                   	pop    %rcx
  13:	c3                   	ret    

Unfortunately, if I then run cargo rustc -p enclave, it will compile the “app” crate again, this time without the instrumentation:

Disassembly of section .text._ZN3app3foo17h0966669265df2a47E:

0000000000000000 <_ZN3app3foo17h0966669265df2a47E>:
   0:	b8 05 00 00 00       	mov    $0x5,%eax
   5:	c3                   	ret    

But I would also be fine with linking the rlib manually to the enclave crate; although then I get this "Unsupported dynamic entry: .init functions" error.

[jethrogb]

It's not clear from your directory tree what your dependency tree looks like. Rlibs are not designed for manual linking, you must use rustc. If you want to change the compile flags for a single crate that's not the top crate, you should modify cargo or run rustc manually for all the crates in your dependency tree.

Closing as this is not really an EDP issue.

[gerritsangel]

Thanks for your answer. My main problem was actually not the Rust linking, but a problem with the init section loaded by the EDP. The init sections is automatically inserted by SanitizerCoverage.

Here is a small example in C of the problem:

int helloworld(int a) {
  return a;
}

If I compile this and link this to the Rust enclave:

$ clang -g -fsanitize-coverage=trace-pc-guard -fPIC helloworld.c -c
$ ar -crs libhelloworld.a helloworld.o
$ mv libhelloworld.a target/x86_64-fortanix-unknown-sgx/debug/deps

I get this error:

Running `ftxsgx-runner-cargo target/x86_64-fortanix-unknown-sgx/debug/enclave`
ERROR: Unsupported dynamic entry: .init functions
ERROR: while running "ftxsgx-elf2sgxs" "target/x86_64-fortanix-unknown-sgx/debug/enclave" "--heap-size" "33554432" "--ssaframesize" "1" "--stack-size" "131072" "--threads" "4" "--debug" got exit status: 1

I've identified the error because LLVM will insert a call to the function module_ctor_trace_pc_guard in the .init_array.2 section. As far as I understand it, this is normally executed before loading, but unfortunately, ftxsgx-elf2sgxs does not seem to support it.

I managed to start the enclave by removing the section with objcopy --remove-section .init_array.2 helloworld.o as the second step, but then the initialization function is not called (I think it may be possible to do it manually, but this seems to get a bit ugly quick).

I wonder if it would be manageable for a relative newcomer to the EDP project to add support for the init sections?

[jethrogb]

I wonder if it would be manageable for a relative newcomer to the EDP project to add support for the init sections?

It would probably be manageable, but Rust has a pretty strict "no life before main" policy. As such, EDP doesn't support it today and it's not clear if it should be supported. Constructors are difficult for verification and determinism, and it would add additional complexity to the entry code, which is a security risk. Is there a way to achieve what you want without constructors?

[gerritsangel]

Ah okay, I see. On the other hand, it works with the normal Rust toolchain. Might also be necessary if C++ libraries are used in the EDP (whether this is a good idea is of course a different question).

I think I can do it manually by removing the init_array section like above and initialize the sancov data structure at the beginning of main manually. I guess I somehow need to manually add an array of function pointers as an exported symbol and then call those manually from Rust.