apache / apache/teaclave-sgx-sdk
Incompatible with hashbrown 0.11
- Dominant language
- Rust
- Stars
- 1.2k
- Forks
- 268
- PR merge metrics
- No merged PRs in 30d
Description
I write enclave code strictly in `no_std` and use `hashbrown` as one of the transitive dependencies. However, it fails to compile after upgrading `hashbrown` to 0.11. It fails at linker step with the following messages:
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::error::os_err':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/error.rs:96: undefined reference to `__xpg_strerror_r'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::util_libc::open_readonly':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/util_libc.rs:110: undefined reference to `open64'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::getrandom_inner::{{closure}}':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:36: undefined reference to `read'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::wait_until_rng_ready':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:104: undefined reference to `poll'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::wait_until_rng_ready::{{closure}}':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:99: undefined reference to `close'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::Mutex::lock':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:124: undefined reference to `pthread_mutex_lock'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::use_file::Mutex::unlock':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/use_file.rs:128: undefined reference to `pthread_mutex_unlock'
/usr/local/bin/ld: target/debug/libenclave.a(getrandom-1afbd7620d110fa6.getrandom.3csxlzm7-cgu.0.rcgu.o): in function `getrandom::imp::getrandom':
/home/USER/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.2/src/linux_android.rs:45: undefined reference to `syscall'
collect2: error: ld returned 1 exit status
The pitfall comes from that `hashbrown 0.11` depends on `getrandom 0.2`. And `getrandom` despite being a `no_std` library will always use Linux syscall if the target triple is `*-linux-*`. See [its document](https://docs.rs/getrandom/0.2.2/getrandom/) for more detail.
Ultimately, I think this just shows a fundamental issue that we tell rust to build enclave code in `x86_64-unknown-linux-gnu` target when in reality we are actually using something like `x86_64-unknown-none-sgx`. As such, `getrandom` got the wrong impression that we are on Linux and it is safe to use Linux syscall.
Of course, we can fork and patch `getrandom`. But IMHO, patching crates for sgx are red herring in terms of maintenance, stability, or even security (as bug fixes in upstream may not be applied in time). Not mentioning it splits the eco systems. I also believe it is infeasible to patch every crates whenever we encounter similar issues. So my question is whether there is a better systematic approach to address the underlying issue.
Thanks.
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce the failure after upgrading hashbrown to 0.11, then inspect the target configuration and the referenced getrandom files: src/error.rs, src/util_libc.rs, src/use_file.rs, and src/linux_android.rs. Determine a systematic way for SGX no_std builds to avoid selecting Linux implementations without requiring per-crate patches; done means the dependency builds for the enclave target with the existing linker constraints.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, rust
- Domain
- embedded-iot, operating-systems, security
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100