tvm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jethrogb <notificati...@github.com>
Subject Re: [dmlc/tvm] [RFC][SGX] Use Fortanix EDP instead of rust-sgx-sdk (#2887)
Date Wed, 15 May 2019 17:40:20 GMT
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
Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message