For others' reference, the [rust-sgx-sdk `Mutex` uses a spinlock provided by the sgx libc](https://github.com/intel/linux-sgx/blob/d10cabebb5512878e84f5d21cdf27c39c428ffe2/sdk/tlibthread/sethread_mutex.cpp#L74).
> depending on untrusted Mutex Right, but all the untrusted OS can do is not provide threads. That only compromises availability, and the untrusted system is always able to harm availability--correctness is not affected. > LibOS-like Rust-SGX environment without any ability to control/audit the > usercalls This is a fair point. Allowing a supposedly secure enclave to trivially access untrusted functions like `fs`, `net`, and `time` is not a good model for users who don't understand the security implications of doing so. The approach of r-s-s which makes these modules private is certainly the more secure approach. For experienced users and library authors, however, usercalls offer greater usability. > pwasm-std FWIW, without wasi, `fs` doesn't compile under `wasm32-unknown-*`. (sys|user)calls aside, pwasm-std unnecessarily limits itself by not including the standard library. Their focus is not security, but rather, ensuring that consensus succeeds. Of course, disallowing structures like `HashMap` is an oversight since their serialization is, in fact, canonical. Similarly with their disallowing floats: it's totally possible to do flops if one "simply" canonicalizes the Wasm NaN representation (or all of the miners use a single architecture). Of course, pwasm is unrelated to the matter at hand :) As another point in favor of the fortanix edp, there's substantially lower overhead from ecalls/ocalls since it transparently implements switchless. Overall, if the TVM runtime using more than just `std::thread` and those threads _weren't_ embarrassingly parallel, I'd be more concerned about security. The main boons of switching are maintainability and usability. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/dmlc/tvm/issues/2887#issuecomment-480180856
