EDP author here. Feel free to ping me any time with any security/support questions regarding Fortanix EDP. Either on GitHub, or on [Slack](https://fortanix.com/runtime-encryption-slack).
> Fortanix EDP is not designed for security, so it has assumptions of trusting > the OS. Both these things are completely, entirely, 100% incorrect. (@dingelish I'd be interested to know how you came to this understanding. I'd also appreciate it if you take security concerns directly to Fortanix instead of claiming incorrect things in a public forum.) In fact, the Fortanix EDP is designed from the ground up to be the most secure and easy to use enclave interface and platform out there. * Unlike every single other enclave platform out there, there is no C code whatsoever in the enclave.† This protects you from dangerous memory safety vulnerabilities exposing your enclave secrets. * There is only a [small interface](https://edp.fortanix.com/docs/api/fortanix_sgx_abi/index.html) with the untrusted environment that is the *same* for all enclaves, such that its security can be evaluated and implementation audited once instead of for each enclave separately. The security implications of every part of this interface have been carefully designed, evaluated, and tested. * Even if you want to use raw user memory for communication, there are user reference primitives for dealing with pointers to user space. These primitives use Rust's borrowing and ownership mechanism to avoid data races and TOCTTOU issues, and also prevent creating dangerous Rust references to user memory. However, we strongly recommend you use byte streams instead, which is why Rust's core byte stream primitive (`std::net::TcpStream`) is made available to developers. * All code that you're required to bring into the enclave (say, to get “hello world” running) is from official Rust repositories, which receive far more scrutiny from 3rd parties than external Rust forks. > For example, the atomicity of EDP's SGX RwLock is untrusted. > ... > Technically, Fortanix EDP maintains an event queue in untrusted space and > RwLock's atomicity roots from it -- resulting in untrusted atomicity. > ... > The JoinHandle is implemented using untrusted Mutex Wrong. All locks are protected using in-enclave state. Yes, there is an event queue in untrusted space. But since enclave state is the source of truth for locks, if userspace decides to ignore the event queue and wake up the wrong thread, nothing bad can happen. Since the OS is already free to schedule/deschedule enclave threads at any time, this gives you the exact same security as using spinlocks, except without the CPU overhead in case locks are held for a long time. > For other input/output, they are all interacting with untrusted input/output > sources. I don't understand your point here, SGX doesn't have trusted I/O. Everyone has to do this. [We recommend](https://edp.fortanix.com/docs/concepts/rust-std/#stream-networking) you use TLS to protect all enclave communications. > they provide a LibOS-like Rust-SGX environment without any ability to > control/audit the usercalls in compile time. It sounds like pushing the > programmers to the edge of a cliff and say: you have the choice to not step > forward. As an experienced researcher, you can hardly got away from the > falling down because too much stuffs depends on their usercalls. The bad > design is not desired by Fortanix, but a result of combining libstd to an > environment without thread/fs/time/env/process/net. Developing for SGX (or for any environment, really) requires the programmer to have certain background knowledge. However, there is only so much the developer can actively keep track off. This is the complexity budget. Everything else that doesn't fit in this budget needs to be reviewed and audited by others. We've clearly chosen a different trade-off here than you. I'd say reviewing your enclave codebase for usage of `std::net` and letting the programmer use familiar interfaces such as HTTP REST and gRPC scores far better in terms of complexity than requiring developers to learn a new language and paradigm (EDL) for describing their enclave interface. > Con: malicious operator could deny availability by blocking network access This is not a drawback specifically of Fortanix EDP. A malicious operator can always do this for any SGX application. Again, feel free to ping me any time with questions. † When using panic=abort. -- 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-492752317
