no_std is broken, doesn't play with sgx

[brenzi]

I'm trying to use this lib within sgx using

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

It seems that #[no_std] is broken as std gets pulled in in places (like context.rs).
Also alloc is not imported

@elichai commented the following: apache/teaclave-sgx-sdk#93 (comment)

I'll need schnorrkel to support sgx for substraTEE

[brenzi]

When I build this crate with

cargo build --release --no-default-features --features "u64_backend alloc"

errors explode.

the low hanging fruit:

diff --git a/src/context.rs b/src/context.rs
index 44d9ab3..ec56bc1 100644
--- a/src/context.rs
+++ b/src/context.rs
@@ -9,7 +9,7 @@
 
 //! ### Schnorr signature contexts and configuration, adaptable to most Schnorr signature schemes.
 
-use std::cell::RefCell;
+use core::cell::RefCell;
 
 use rand::prelude::*;  // {RngCore,thread_rng};

But that doesn't do the trick by far

[burdges]

I've pushed a fix that passes your build command. It suffices? Thanks!

I'll publish a new version soon, but we've several compatibility breaks already in master and..

I'd love to resolve #9 along with the other compatibility breaks, but so far nothing conclusive arose. I'll make a decision there asap. :)

[burdges]

Appears ed25519-dalek lacks this extern crate alloc; that I needed, so not sure if I fixed those errors correctly or not.

[brenzi]

Cheers for your attempt to fix this issue.

I now get

error[E0658]: use of unstable library feature 'alloc': this library is unlikely to be stabilized in its current form or name (see issue #27783)
   --> /home/abrenzikofer/.cargo/git/checkouts/schnorrkel-0d699dd19a5d19bc/bc1cf8e/src/lib.rs:262:1
    |
262 | extern crate alloc;
    | ^^^^^^^^^^^^^^^^^^^
    |
    = help: add #![feature(alloc)] to the crate attributes to enable

error: aborting due to previous error

So I must guess this issue isn't fixed just yet - not only because of upstream crate ed25519-dalek

[brenzi]

edit: sorry, this issue should be fixed by updating rust nightly

There are further issues when building without alloc feature:

> cargo build --release --no-default-features --features "u64_backend"
error[E0432]: unresolved import `crate::sign::verify_batch`
   --> src/lib.rs:308:50
    |
308 | pub use crate::sign::{Signature,SIGNATURE_LENGTH,verify_batch};
    |                                                  ^^^^^^^^^^^^ no `verify_batch` in `sign`

error[E0433]: failed to resolve: use of undeclared type or module `BTreeMap`
   --> src/musig.rs:373:22
    |
373 |         let mut Rs = BTreeMap::new();
    |                      ^^^^^^^^ use of undeclared type or module `BTreeMap`

...

[brenzi]

Doesn't build with rustsgx-sdk. Compiler still complains:

error: duplicate lang item in crate `std`: `f32_runtime`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `f64_runtime`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `panic_impl`.
  |
  = note: first defined in crate `sgx_tstd`.

error: duplicate lang item in crate `std`: `oom`.
  |
  = note: first defined in crate `sgx_trts`.

It looks like one or more of your dependencies don't support no_std: merlin ?

[burdges]

If I understand, the #![feature(alloc)] error comes form your rust being outdated, yes?

I've fixed the issues I understood and pushed the changes, in part by omitting musig without alloc or std. I even made cargo test .. work with various combinations, which eve dalek does not do.

I still do not understand why ed25519-dalek does not require extern crate alloc; like schnorrkel seemingly does. An edition setting in Cargo.toml maybe?

I also do not understand the no_std: merlin issue. I know merlin's tests use strobe-rs, which requires Vec, but outside tests I'm unsure about the problem. Can you pin down the actual problem?

[burdges]

There is a serious dependency flaw caused by the rand crate being chopped up into too many poinless subcrates: rust-random/rand#738 Is that the problem? I'm afraid merlin does create an Rng, but some workaround exist I think.

[burdges]

Or maybe my Cargo.toml does not pass through some feature flags correctly?

[brenzi]

right now we're trying to use ed25519 signatures with our node as a workaround. I'll revert when I find time for further debugging

[burdges]

I've found the problem maybe.. merlin lacks any support for no_std, like you said.

I believe https://github.com/dalek-cryptography/merlin/blob/master/src/strobe.rs#L4 might be the only problematic line in merlin. Can you tell if using this branch of merlin works? It merely uses use core::ops::{Deref, DerefMut}; and passes through the std feature.

[burdges]

It appears my second commit there to Cargo.toml breaks their CI, but the first seemingly passed fine. It's maybe not required to pass through the std dependency unless you really use functionality only present with std I guess?

[brenzi]

I just tried to use your merlin branch within sgx. no success. Same duplicate lang item error as above

toml:

merlin = { git ="https://github.com/burdges/merlin.git", branch="no_std", default-features = false}

code:

extern crate merlin;
use merlin::{Transcript};