dependency upgrade

[bradyjoestar]

We currently need to fork a new repo and change it when we want to use any project from rust ecosystem.

I'm not sure but is any way that we could use it origin code without changing any LOC? i.e:

• use libos such as https://github.com/occlum/libos and https://github.com/oscarlab/graphene?
• or any possible solution?

[dingelish]

I cannot see any solution of checking if a crate is compatible with Intel SGX unless manually port it using rust-sgx-sdk.

libos sounds like a solution. However, libos based solutions provide less safety/security/compatibility guarantees, because they do not provide statically controlled I/O interfaces.

One can always use libos based solution (including Fortanix's rust-sgx, in fact it is a libos!) to port crates. But he/she would never know if the entire dependency tree read/write from untrusted fs/env variable, or invoke dangerous syscalls during compile. All of these checks can be done during execution, but it'll generate unpredictable events and bring in indeterminism -- which is almost unacceptable for SGX applications.

In the large number of crates I've been porting or ported, I found lots of incompatible or very tricky points which can only be found by using this rust-sgx-sdk. For example, uuid-rs, parity-wasm and wasmi require TCSPolicy=0 for bounding thread to OS thread -- the other libos based solutions would never tell you that!

[dingelish]

An inevitable work during porting is to decide to use the trusted or untrusted file system/time. With libos one can hardly know all of the fs/time access in an enclave with lots of dependencies.

[dingelish]

One interesting case we find is that Box::new would construct an object on the stack before moving it to the heap. Existing solutions such as copyless does not solve it at all (you can verify it using a small stack sgx enclave).

Finally, I got a solution realbox. If you're using libos, you'll never now that! (you'll get sigill errors for no reason)

[dingelish]

another interesting case is heapsize. it needs special libc allocator function. my port includes the specific implementation:

https://github.com/mesalock-linux/heapsize-sgx/blob/master/src/lib.rs#L379

[bradyjoestar]

Thanks for your professional advice!

I have read your article https://github.com/dingelish/SGXfail/blob/master/05.md creafully and the problems what you mentioned seem existed both in occlum/libos and Fortanix/rust-sgx

A trustworthy libos is more than it, I mean, it shouldn't depend any untrusted component from hostOS,include thread,mutex,time,fs...

Thanks for your great work on it!

Maybe we could develop a trustworthy libos but it must depend on your prior work? Although x86 couldn't provide trusted time.

If any c-application run with libos, it should use libos own thread strategy but not ocall to hostOS.

As for compile, maybe use reproduce build, we could find the dangerous attack from hostos if we check the mr_enclave?

Happy Dragon Boat Festival!

[bradyjoestar]

I am sleepless when I image thousands of sgx-pod is running on the kubernetes. :-)