Tracking issue: platform-specific APIs for SGX target

[jethrogb]

This issue tracks the functionality available behind the sgx_platform feature gate.

Relevant PRs:

• Add std::os::fortanix_sgx module #56978
• Add io and arch modules to std::os::fortanix_sgx #57119

TODO:

• arch module
  • More details in Expose EGETKEY/EREPORT fortanix/rust-sgx#15
  • At the very least the AlignXXX<[u8; _]> types should be replaced by the actual types (from the sgx-isa crate). Concern: that would make std dependent on the bitflags crate.
• ffi module
  • No concerns
• io module
  • No concerns
• mem module
  • No concerns, but no evidence of real-world usage
• thread module
  • No concerns
• usercalls module
  • This is all pretty untested outside of std

For more information about the target, see https://edp.fortanix.com

[joshtriplett]

cc @jsakkine-intel

[ghost]

Thanks. Interesting development. I haven't really followed Fortanix SGX stack development that closely. If I wanted to write a test program with this what would be the easy steps to get started?

[jethrogb]

@jsakkine-intel the toolchain is still in flux, the steps keep changing quite frequently these days. Right now, this should do it (if you have PSW & SDK driver installed):

rustup update nightly
cargo install xargo
cargo install sgxs-tools --version 0.6.0-rc1
cargo install fortanix-sgx-tools --version 0.1.0-rc1
# Soon, instead: cargo install fortanix-sgx-tools --git https://github.com/fortanix/rust-sgx
cargo new --bin sgxtest
cd sgxtest
echo '[target.x86_64-fortanix-unknown-sgx.dependencies.std]' > Xargo.toml
xargo build --target x86_64-fortanix-unknown-sgx
ftxsgx-elf2sgxs target/x86_64-fortanix-unknown-sgx/debug/sgxtest --heap-size 0x20000 --ssaframesize 1 --stack-size 0x20000 --threads 1 --debug
sgxs-append -i target/x86_64-fortanix-unknown-sgx/debug/sgxtest.sgxs
ftxsgx-runner target/x86_64-fortanix-unknown-sgx/debug/sgxtest.sgxs

[yonimo]

Hi, my name is Yoni Moses and I work for a startup called Fireblocks. We are developing our core technology on SGX, that's why our main language was C++ until now. For a long time we have considered using Rust instead of C++. We've found a number of unofficial modules that tried to adopt Rust to run on SGX platform. However, for us it was amazing news to see that you guys have started to add SGX as an official target for Rust on main repository.
We would like to understand what is the status of the project, do you have any estimation when do you think it will be ready to be merged to stable or release branches? Do you think that it's possible to use it just now? What is your recommendation for using Rust on SGX?

[jethrogb]

@yonimo the x86_64-fortanix-unknown-sgx target is a core part of the Fortanix Enclave Development Platform (EDP). The goal of the EDP is to be the best way to write SGX applications (in every way: ease of use, performance, security). It differs significantly from other existing enclave platforms in how you write your application, in that you're not expected to write much (or any) outside-of-the-enclave code. Your enclave starts at Rust's fn main. There's bare-bones instructions at fortanix/rust-sgx#49 on how to use it in the current state. We plan to have a website and documentation out in a week or two. Please give it a try and let me know how it goes! Feel free to contact me on slack as well with any questions - https://fortanix.com/runtime-encryption-slack

[sanxiyn]

Presumably, the new website is https://edp.fortanix.com/

[jethrogb]

Indeed

[nhynes]

Hello, any update on this? It'd be nice to start using stable Rust after over a year!

[jethrogb]

@nhynes Which APIs do you want to use in particular? Just EREPORT/EGETKEY or others as well?

[nhynes]

Just EREPORT/EGETKEY or others as well?

Yep, those are the ones.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. The only part of this that seems lang-specific is the intrinsics; everything else appears to be the domain of libs.

Of the intrinsics, we were wondering, since we have subsequently shipped asm!, is there substantial value in having intrinsics for SGX-specific instructions, or can we just ask the SGX libraries to use asm! and provide wrappers for that?

[jethrogb]

Sure, but couldn't you ask the same question of every other intrinsic?