Using std Aware Cargo

[mssun]

"std Aware Cargo" (https://github.com/rust-lang/wg-cargo-std-aware) is one of the most important building blocks for Teaclave SGX SDK. With this, we can build SGX enclave without worry about the complexity brought by Xargo or no-std Cargo. However this is a long-term plan for Cargo, which doesn't gain higher priority from the community.

Recently, I found that they already has an MVP implementation (https://github.com/rust-lang/wg-cargo-std-aware#mvp-implementation). This supports an option called build-std to build std/core/compiler-builtins from sources. However, the MVP implementation only partially solves our issue. I didn't see any further plan further.

However, I found the build-std option may good enough for us. I created a repository to show the possibility of using it: https://github.com/mssun/build-std.

If you're interested in this, please help me to figure out if there're any potential difficulties of using build-std.

[sammyne]

I think the build-std option will improve this SDK greatly, which will helps in stuff like removing the std::prelude::v1::* from SGX-ported crates. So I will give it a shot this weekend 😄

[dingelish]

@mssun thanks! i'll create a branch for rust-sgx-sdk, based on your build-std repo :-)

[PiDelport]

Related tracking issue / discussion: https://github.com/rust-lang/wg-cargo-std-aware/issues/3

[cschramm]

I happened to give this a try and built a drop-in replacement for std, see https://github.com/yaxitech/incubator-teaclave-sgx-sdk/commit/41ae223d6458db488b938927015c643720b416ef. I can build an internal project that depends on things like reqwest just fine with the resulting sysroot. The only patch I have to apply is to remove the cdylib crate-type from hyper.

Of course the result cannot actually run as syscalls get linked in from glibc via the libc crate, heavily used by mio and socket2. Such crates either still have to get adapted "sgx-world-style" or be provided with a libc replacement / extension that builds on ocalls or whatever is appropriate for the required syscall functions.

(By the way, this is basically a duplicate of #75.)

[volcano0dr]

@cschramm Thank you very much for your detailed problem analysis and test report.

I plan to support three build strategies in the next release:

1. no_std
2. build-std in xargo (using xargo build)
3. build-std in cargo (using cargo-std-aware)

In my current work in progress, most of the base crates builds are good using build-std build strategy, e.g. mio, serde, rustls, etc. But compatibility is still a tricky issue, e.g., the problem mentioned in your report, SGX unsupported instructions (cpuid, syscall, etc.).

Compatibility issues that I often encounter in my testing.

1. libc::syscall
2. unsupported libc api (not implemented via ocall in sgx_libc)
3. cpuid instruction

For incompatible third-party crates, it can be resolved by the following ways:

1. Provide a compatible API.
2. Manually port the third-party crates to adapt to SGX env, and then override the dependent crate on crate.io with [patch] in Cargo.toml.

[volcano0dr]

@cschramm @PiDelport teaclave-sgx-sdk v2.0.0(https://github.com/apache/incubator-teaclave-sgx-sdk/tree/v2.0.0-preview) already supports compiling enclave with cargo-std-aware.