Is it possible to use this library along with `aws-nitro-enclaves-sdk-c`?

[sify21]

Problem:

I want to use this library in a rust project (for its fips feature), and I also want to use https://github.com/aws/aws-nitro-enclaves-sdk-c. Since aws-nitro-enclaves-sdk-c has no rust-port, I have to call it through ffi.

The problem is aws-nitro-enclaves-sdk-c also depends on aws-lc, thus I have to include this line in my build.rs

println!("cargo:rustc-link-lib=dylib=crypto");

Then my project will fail when linking with cc

  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: /usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/libcrypto.a(bcm.c.o): In function `is_fips_build':
          /tmp/crt-builder/aws-lc/build/../crypto/fipsmodule/service_indicator/service_indicator.c:12: multiple definition of `is_fips_build'
          /target/x86_64-unknown-linux-gnu/debug/deps/libaws_lc_fips_sys-b54d10fa53b14c20.rlib(bcm.o):/home/sify/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aws-lc-fips-sys-0.13.8/aws-lc/crypto/fipsmodule/service_indicator/service_indicator.c:12: first defined here
          collect2: error: ld returned 1 exit status

I don't know how to get around this problem.

Solution:

A possible solution would be that aws-lc-rs provides a feature which turns off the internal building of aws-lc by itself, and depends on system library that I specified in my project. I don't know if it's possible.

[justsmth]

Hello!

Support for linking to an existing build of AWS-LC is not something that we currently support, but we have in our backlog.

In this case, the specific blocking issue seems to be that this symbol was not prefixed for our build of aws-lc-fips-sys. For the aws-lc-sys build, it gets prefixed:

❯ nm --extern-only target/debug/build/aws-lc-sys-e1b37d294c11b64d/out/f8e4fd781484bd36-bcm.o | grep is_fips_build
000000000005a4dc T _aws_lc_0_32_2_is_fips_build

... but not for aws-lc-fips-sys:

❯ nm --extern-only target/debug/build/aws-lc-fips-sys-9778ffcea10b435a/out/build/aws-lc/crypto/fipsmodule/bcm.o | grep is_fips_build
00000000000515c0 T _is_fips_build

Another possible work-around might be to to use the "libcrypto" that's built by aws-lc-fips-sys when building aws-nitro-enclaves-sdk-c. I believe s2n-tls-sys does something similar to that here.

I will look into why the is_fips_build symbol is not properly prefixed for aws-lc-fips-sys. Fixing this should unblock a build needing to link to both.

[sify21]

Currently I'm not building aws-nitro-enclaves-sdk-c myself, I'm using the convenient containers provided by it

docker build -f containers/Dockerfile.al2 --target builder -t aws-nitro-enclaves-sdk-c .

In the container, relevant libraries are built as static .a archives.
Then in my project I just used bindgen to generate the interfaces and printed linking instructions in the build script (which caused me some time to figure out the correct linking order, see aws/aws-nitro-enclaves-sdk-c#160) .

I'll try to build it from source before symbols are properly prefixed for aws-lc-fips-sys. I suppose I should reference https://doc.rust-lang.org/cargo/reference/build-script-examples.html#using-another-sys-crate to leverage existing aws-*-sys crates.

[justsmth]

I believe I've got a setup to reproduce this problem: https://github.com/aws/aws-lc-rs/actions/runs/18472619734/job/52629866074?pr=917

  = note: rust-lld: error: duplicate symbol: is_fips_build
          >>> defined at service_indicator.c:12 (/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aws-lc-fips-sys-0.13.7/aws-lc/crypto/fipsmodule/service_indicator/service_indicator.c:12)
          >>>            bcm.o:(is_fips_build) in archive /home/runner/.cargo/target/7e/21ec275d379110/debug/deps/libaws_lc_fips_sys-471bf098f6eda4e3.rlib
          >>> defined at service_indicator.c:12 (/home/runner/work/aws-lc-rs/aws-lc-rs/aws-lc-fips-sys/aws-lc/crypto/fipsmodule/service_indicator/service_indicator.c:12)
          >>>            bcm.o:(.text+0xc696c) in archive /home/runner/.cargo/target/7e/21ec275d379110/debug/deps/libaws_lc_fips_sys-9fb0278824dec2d6.rlib

I kinda doubt that I will be able to fully remediate this issue in the current aws-lc-fips-sys v0.13.x versions due to changes that would likely be needed within the "FIPS module". However, I can try to minimize the number of symbols that conflict.