Add symbol prefixing feature for BoringSSL

[BarbossHack]

Goal

Add a prefix to all symbols in libcrypto and libssl to prevent conflicts with other OpenSSL or BoringSSL versions that might be linked in the same process.

Why?

When statically linking both OpenSSL and BoringSSL in the same project, we encountered duplicate symbols, for example:

rust-lld: error: duplicate symbol: AES_encrypt
>>> defined at aes-x86_64.s:328 (crypto/aes/aes-x86_64.s:328)
>>>            libcrypto-lib-aes-x86_64.o:(AES_encrypt) in archive /home/user/debug/target/debug/deps/libopenssl_sys-aa966f6339bd703d.rlib
>>> defined at aes.c:62 (/home/user/debug/target/debug/build/boring-sys-daeba9923fc21b33/out/boringssl/src/crypto/fipsmodule/aes/aes.c:62)
 >>>            bcm.c.o:(.text.AES_encrypt+0x0) in archive /home/user/debug/target/debug/deps/libboring_sys-b3f993188e8b17ea.rlib

How?

The first approach was to use the BoringSSL-provided Go script make_prefix_headers.go. It mostly worked, but:

• It required two compilation steps: first to build the static libraries and extract symbols with read_symbols.go, then to generate boringssl_prefix_symbols.h with make_prefix_headers.go, and finally rebuild again the static libraries with this header. (We could have prebuilt it like gRPC does, but I preferred a fully automated workflow.)
• Some ASM/Perl-generated symbols were missed (even if present in boringssl_prefix_symbols.h), which I ended up fixing with the Binutils objcopy tool, not very straightforward.
• It required Go to run.

Therefore, I decided to use only the Binutils tools nm and objcopy to fully automate the symbol prefixing.

Steps (build.rs):

1. List static libraries to prefix symbols in (libssl.a and libcrypto.a).
2. Use nm to list all exported symbols in these static libraries.
3. Generate a mapping file and use objcopy to prefix all symbols.
4. Update the generated bindings (bindings.rs) with #[link_name] where necessary.

Cross-compilation

Currently, this workflow is tested for Linux and Android only.

For Android, the target-specific nm and objcopy from the NDK are used.

macOS/iOS and Windows toolchains are not tested. I currently don’t have access to a macOS environment and have limited experience with Windows toolchains.

Usage

I've added an opt-in feature prefix-symbols, as it is not tested on macOS/iOS/Windows yet.

cargo add boring2 --features prefix-symbols

[0x676e67]

Thanks for fixing this issue. It seems there’s a merge conflict — could you help resolve it?

[0x676e67]

Additionally, GitHub Actions provides macOS and Windows environments, which makes testing on those platforms possible. I think you should also add a GitHub Actions workflow to ensure everything works correctly across different platforms.

[BarbossHack]

Thanks for fixing this issue. It seems there’s a merge conflict — could you help resolve it?

I created this branch about a month ago and overlooked opening the PR. I’ll resolve the merge conflict now 👍

[BarbossHack]

I think you should also add a GitHub Actions workflow to ensure everything works correctly across different platforms.

I'll look into it 👍

Additionally, GitHub Actions provides macOS and Windows environments, which makes testing on those platforms possible.

I’m not fully confident with this yet, but I'll give it a try and see how far I can get.

[0x676e67]

done?

[BarbossHack]

Not yet. As I mentioned upstream (in cloudflare/boring), I have only managed to add GitHub Actions for Linux and Android so far. For now, I have added a check to ensure that no one can use this feature on macOS/iOS/Windows (the build will panic).

I am still struggling with macOS and Windows:

• macOS: The main issue is that, by default, macOS does not complain when the same symbol is defined multiple times. This makes it difficult to test whether my symbol prefixing works correctly and prevents runtime segmentation faults (which already happen without my feature). And I also encounter relocation failures and else... I need to investigate this further, but it is not straightforward.

• Windows: I am facing a different issue that is unrelated to symbol prefixing. The openssl-sys build fails due to a Perl-related problem. I may be missing some dependencies in the Windows GitHub runner setup. I have only spent a limited amount of time on this so far.

If you are okay with merging this with only Linux and Android support, I will continue working on Windows and macOS support in a follow-up PR.

[0x676e67]

We can initially support Linux/Android, but at least we should provide compilation errors for non-supported platforms.

#[cfg(feature = "prefix-symbols")]
compile_error!("not supports....");

[BarbossHack]

I've added this in build/main.rs (main function)

if config.features.prefix_symbols && ["macos", "ios", "windows"].contains(&config.target_os.as_str())
{
        panic!("The `prefix_symbols` feature is not supported on macOS/iOS or windows targets.");
}

[0x676e67]

Could you also fix Clippy at the same time? It is suggested to place the "prefix-symbols ci job" directly at the end of the ci.yml file. This will make the testing process more convenient. Additionally, on Windows, the CMake version needs to be downgraded to 0.1.54 in order to fix the testing issue.

[BarbossHack]

The Clippy issues are not in the code I added, but I can fix them 👍

Same for the Windows CI not passing, I didn't modify the Windows CI, but I can look into it

It is suggested to place the "prefix-symbols ci job" directly at the end of the ci.yml file. This will make the testing process more convenient.

Sure, I'll do that 👍 (I've made it a separated file so that it would be easier to merge upstream)

[BarbossHack]

ci.yml and clippy: done ✔️

the CMake version needs to be downgraded to 0.1.54 in order to fix the testing issue.

cmake already appears to be set to version "0.1.54" in the workspace's Cargo.toml, do I need to strictly pin it to "=0.1.54" ?

[0x676e67]

ci.yml and clippy: done ✔️

the CMake version needs to be downgraded to 0.1.54 in order to fix the testing issue.

cmake already appears to be set to version "0.1.54" in the workspace's Cargo.toml, do I need to strictly pin it to "=0.1.54" ?

to ci: https://github.com/cloudflare/quiche/pull/2285/changes

[BarbossHack]

Done ✔️

[0x676e67]

It seems that the 32-bit operating system still has some issues. My suggestion is to abandon supporting 32-bit?

Some tests still haven't passed: https://github.com/0x676e67/boring2/actions/runs/20210077959/job/58014693403?pr=103

[BarbossHack]

Weird, it's working on my github actions https://github.com/BarbossHack/boring2/actions/runs/20194237006

Maybe moving it to ci.yml changed something... I could fix it, but yeah I think we can drop 32 bit support, especially since i686-linux-android has long standing issues when building openssl (with -latomic), which are unrelated to the boringssl symbol prefixing

[0x676e67]

Check if there are any areas that need to be cleaned. If not, we can combine them.

[BarbossHack]

You mean combining all the job steps in 1 step?