search

paritytech / substrate

Substrate: The platform for blockchain innovators
Apache License 2.0
8.39k stars 2.65k forks source link

make #[global_allocator] optional #2417

Closed brenzi closed 5 years ago

brenzi commented 5 years ago

I'm using various substrate crates for our project running in SGX enclaves using

https://github.com/baidu/rust-sgx-sdk.git

Currently I'm struggling because SGX SDK defines its global_allocator: https://github.com/baidu/rust-sgx-sdk/blob/9d4fa0f603e44bb82efae9d913c586a498b7d9da/sgx_tstd/src/lib.rs#L100

And substrate does so as well: https://github.com/paritytech/substrate/blob/f4ced94012d78368a2cdd58dcc6277d843fdf11c/core/sr-std/without_std.rs#L29

This leads to an error:

error: the #[global_allocator] in sgx_tstd conflicts with this global allocator in: sr_std

could we have substrate's global_allocator configurable? With a feature?

gavofyork commented 5 years ago

No - the substrate runtime must compile to no-std Wasm and therefore cannot depend on any crates that require std. If you need some functionality from a crate that depends on std, either alter the crate to create a no-std variant of it or (much more effort) introduce off-chain logic through Inherents and/or off-chain workers that can let certain nodes provide such functionality from outside of the runtime.

Using SGX from within a WebAssembly-compiled code blob was never going to work.

brenzi commented 5 years ago

Agree with your statement, but my goal goes the other way round: I'd like to use i.e. sr_primitives (no_std) from within SGX enclave code (to compose and sign an extrinsic within an sgx enclave) . I'm not trying to do sgx within wasm. It's like running subkey within sgx. So SGX needs no_std as well and defines its own global_allocator.

My pull request shows that it doesn't interfere with substrate yet it solves my problem.

gavofyork commented 5 years ago

Ahh, sorry I misread. Yeah fair enough then.