fortanix/rust-sgx

The Fortanix Rust Enclave Development Platform

Fortanix Rust Enclave Development Platform

The Fortanix Rust EDP is the preferred way to write Intel SGX enclaves from scratch.

Get started now.

# Install EDP components
rustup target add x86_64-fortanix-unknown-sgx --toolchain nightly
cargo install fortanix-sgx-tools sgxs-tools
echo >> ~/.cargo/config -e '[target.x86_64-fortanix-unknown-sgx]\nrunner = "ftxsgx-runner-cargo"'

# Check your SGX setup
sgx-detect

# Run your enclave!
cargo new --bin hello-world
cd hello-world
cargo run --target x86_64-fortanix-unknown-sgx

Documentation

Looking for the in-enclave source code? Check out the rust-lang/rust repository.

Note for maintenance

About creating release and publishing to crates.io

The Publish Crates workflow can be triggered or by creating new Release: please ensure the tag name used for the new release following format: ${crate name}_v{version number} , although in this workflow only ${crate name} is used, but {version number} is still required for keeping a good tag name.

Contributing

We gratefully accept contributions from the community. By participating in this community, you agree to abide by Code of Conduct.

Here are some ways to contribute:

1. Participate in the #rust-sgx channel of the Runtime Encryption community on Slack.
2. File bug reports.
3. Help design new features.
4. Contribute code via pull requests.

All contributions are covered under the Developer's Certificate of Origin (DCO).

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

License

This project is primarily distributed under the terms of the Mozilla Public License (MPL) 2.0, see LICENSE for details.

rust-sgx's Issues

Improve error handling

There's a fair amount of unwrap use in places.

Expose usercall primitives

For experimentation, it would be useful to have the usercall primitives accessible outside std. For example, in std::os::sgx.

enclave_example fails to compile

When I try to compile the example it fails. Tried to install different versions of Rust with no luck.

`$ cargo build-enclave -H 0x10000 -S 0x10000
Compiling enclave v0.1.0
Compiling sgxs v0.4.0
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 error: the trait bound '_mut u8: core::marker::Send' is not satisfied [E0277]
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64 pub static USER_HEAP: Mutex<Option<Heap<'static>>> = Mutex::new(None);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 help: run 'rustc --explain E0277' to see a detailed explanation
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 note: '_mut u8' cannot be sent between threads safely
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 note: required because it appears within the type 'alloc_buddy_simple::Heap<'static>'
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 note: required because it appears within the type 'core::option::Option<alloc_buddy_simple::Heap<'static>>'
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 note: required because of the requirements on the impl of 'core::marker::Sync' for 'spin::Mutex<core::option::Option<alloc_buddy_simple::Heap<'static>>>'
/home/runjet/.cargo/registry/src/github.com-1ecc6299db9ec823/enclave-0.1.0/src/alloc.rs:64:1: 64:71 note: shared static variables must have a type that implements 'Sync'
error: aborting due to previous error
Build failed, waiting for other jobs to finish...
error: Could not compile 'enclave'.

To learn more, run the command again with --verbose.
Error: CargoBuildExec(Status(ExitStatus(ExitStatus(25856))))
error: `

Make enclave-runner async

Currently, enclave-runner runs one thread per enclave thread. Alternatively, it could schedule a large number of enclave threads on a fixed number of users threads.

hide unnecessary functions exported by libunwind.a

Fortanix's port of llvm-project for linking libunwind with x86_64-fortanix-unknown-sgx exports a few functions like fprintf which it need not. These functions are implemented in llvm-project/blob/release/5.x/libunwind/src/UnwindRustSgx.c.

aesm-client: Implement Rust API guidelines

• Naming (crate aligns with Rust naming conventions)
  • Casing conforms to RFC 430 (C-CASE)
  • Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
  • Getter names follow Rust convention (C-GETTER)
  • Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
  • Iterator type names match the methods that produce them (C-ITER-TY)
  • Feature names are free of placeholder words (C-FEATURE)
  • Names use a consistent word order (C-WORD-ORDER)
• Interoperability (crate interacts nicely with other library functionality)
  • Types eagerly implement common traits (C-COMMON-TRAITS)
    • Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
      Display, Default
  • Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
  • Collections implement FromIterator and Extend (C-COLLECT)
  • Data structures implement Serde's Serialize, Deserialize (C-SERDE)
  • Types are Send and Sync where possible (C-SEND-SYNC)
  • Error types are meaningful and well-behaved (C-GOOD-ERR)
  • Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
  • Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)
• Macros (crate presents well-behaved macros)
  • Input syntax is evocative of the output (C-EVOCATIVE)
  • Macros compose well with attributes (C-MACRO-ATTR)
  • Item macros work anywhere that items are allowed (C-ANYWHERE)
  • Item macros support visibility specifiers (C-MACRO-VIS)
  • Type fragments are flexible (C-MACRO-TY)
• Documentation (crate is abundantly documented)
  • Crate level docs are thorough and include examples (C-CRATE-DOC)
  • All items have a rustdoc example (C-EXAMPLE)
  • Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
  • Function docs include error, panic, and safety considerations (C-FAILURE)
  • Prose contains hyperlinks to relevant things (C-LINK)
  • Cargo.toml includes all common metadata (C-METADATA)
    • authors, description, license, homepage, documentation, repository,
      readme, keywords, categories
  • Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
  • Release notes document all significant changes (C-RELNOTES)
  • Rustdoc does not show unhelpful implementation details (C-HIDDEN)
• Predictability (crate enables legible code that acts how it looks)
  • Smart pointers do not add inherent methods (C-SMART-PTR)
  • Conversions live on the most specific type involved (C-CONV-SPECIFIC)
  • Functions with a clear receiver are methods (C-METHOD)
  • Functions do not take out-parameters (C-NO-OUT)
  • Operator overloads are unsurprising (C-OVERLOAD)
  • Only smart pointers implement Deref and DerefMut (C-DEREF)
  • Constructors are static, inherent methods (C-CTOR)
• Flexibility (crate supports diverse real-world use cases)
  • Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
  • Caller decides where to copy and place data (C-CALLER-CONTROL)
  • Functions minimize assumptions about parameters by using generics (C-GENERIC)
  • Traits are object-safe if they may be useful as a trait object (C-OBJECT)
• Type safety (crate leverages the type system effectively)
  • Newtypes provide static distinctions (C-NEWTYPE)
  • Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
  • Types for a set of flags are bitflags, not enums (C-BITFLAG)
  • Builders enable construction of complex values (C-BUILDER)
• Dependability (crate is unlikely to do the wrong thing)
  • Functions validate their arguments (C-VALIDATE)
  • Destructors never fail (C-DTOR-FAIL)
  • Destructors that may block have alternatives (C-DTOR-BLOCK)
• Debuggability (crate is conducive to easy debugging)
  • All public types implement Debug (C-DEBUG)
  • Debug representation is never empty (C-DEBUG-NONEMPTY)
• Future proofing (crate is free to improve without breaking users' code)
  • Sealed traits protect against downstream implementations (C-SEALED)
  • Structs have private fields (C-STRUCT-PRIVATE)
  • Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
  • Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
• Necessities (to whom they matter, they really matter)
  • Public dependencies of a stable crate are stable (C-STABLE)
  • Crate and its dependencies have a permissive license (C-PERMISSIVE)

enclave-runner: Implement Rust API guidelines

• Naming (crate aligns with Rust naming conventions)
  • Casing conforms to RFC 430 (C-CASE)
  • Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
  • Getter names follow Rust convention (C-GETTER)
  • Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
  • Iterator type names match the methods that produce them (C-ITER-TY)
  • Feature names are free of placeholder words (C-FEATURE)
  • Names use a consistent word order (C-WORD-ORDER)
• Interoperability (crate interacts nicely with other library functionality)
  • Types eagerly implement common traits (C-COMMON-TRAITS)
    • Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
      Display, Default
  • Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
  • Collections implement FromIterator and Extend (C-COLLECT)
  • Data structures implement Serde's Serialize, Deserialize (C-SERDE)
  • Types are Send and Sync where possible (C-SEND-SYNC)
  • Error types are meaningful and well-behaved (C-GOOD-ERR)
  • Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
  • Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)
• Macros (crate presents well-behaved macros)
  • Input syntax is evocative of the output (C-EVOCATIVE)
  • Macros compose well with attributes (C-MACRO-ATTR)
  • Item macros work anywhere that items are allowed (C-ANYWHERE)
  • Item macros support visibility specifiers (C-MACRO-VIS)
  • Type fragments are flexible (C-MACRO-TY)
• Documentation (crate is abundantly documented)
  • Crate level docs are thorough and include examples (C-CRATE-DOC)
  • All items have a rustdoc example (C-EXAMPLE)
  • Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
  • Function docs include error, panic, and safety considerations (C-FAILURE)
  • Prose contains hyperlinks to relevant things (C-LINK)
  • Cargo.toml includes all common metadata (C-METADATA)
    • authors, description, license, homepage, documentation, repository,
      readme, keywords, categories
  • Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
  • Release notes document all significant changes (C-RELNOTES)
  • Rustdoc does not show unhelpful implementation details (C-HIDDEN)
• Predictability (crate enables legible code that acts how it looks)
  • Smart pointers do not add inherent methods (C-SMART-PTR)
  • Conversions live on the most specific type involved (C-CONV-SPECIFIC)
  • Functions with a clear receiver are methods (C-METHOD)
  • Functions do not take out-parameters (C-NO-OUT)
  • Operator overloads are unsurprising (C-OVERLOAD)
  • Only smart pointers implement Deref and DerefMut (C-DEREF)
  • Constructors are static, inherent methods (C-CTOR)
• Flexibility (crate supports diverse real-world use cases)
  • Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
  • Caller decides where to copy and place data (C-CALLER-CONTROL)
  • Functions minimize assumptions about parameters by using generics (C-GENERIC)
  • Traits are object-safe if they may be useful as a trait object (C-OBJECT)
• Type safety (crate leverages the type system effectively)
  • Newtypes provide static distinctions (C-NEWTYPE)
  • Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
  • Types for a set of flags are bitflags, not enums (C-BITFLAG)
  • Builders enable construction of complex values (C-BUILDER)
• Dependability (crate is unlikely to do the wrong thing)
  • Functions validate their arguments (C-VALIDATE)
  • Destructors never fail (C-DTOR-FAIL)
  • Destructors that may block have alternatives (C-DTOR-BLOCK)
• Debuggability (crate is conducive to easy debugging)
  • All public types implement Debug (C-DEBUG)
  • Debug representation is never empty (C-DEBUG-NONEMPTY)
• Future proofing (crate is free to improve without breaking users' code)
  • Sealed traits protect against downstream implementations (C-SEALED)
  • Structs have private fields (C-STRUCT-PRIVATE)
  • Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
  • Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
• Necessities (to whom they matter, they really matter)
  • Public dependencies of a stable crate are stable (C-STABLE)
  • Crate and its dependencies have a permissive license (C-PERMISSIVE)

Test linker compatibility

In the past, binutils 2.26.1 has been recommended. Testing is needed to see if this restriction still applies. If it does apply, consider switching to rust-lld.

Issue linking libunwind in release mode when using LTO

ring$ cargo +nightly rustc --test quic_tests --release --target=x86_64-fortanix-unknown-sgx -- -C codegen-units=1
   Compiling ring v0.14.2 (~/projects/rust-sgx/hello/ring)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-fuse-ld=gold" "-nostdlib" "-shared" "-Wl,-e,sgx_entry" "-Wl,-Bstatic" "-Wl,--gc-sections" "-Wl,-z,text" "-Wl,-z,norelro" "-Wl,--rosegment" "-Wl,--no-undefined" "-Wl,--error-unresolved-symbols" "-Wl,--no-undefined-version" "-Wl,-Bsymbolic" "-Wl,--export-dynamic" "-L" "~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-fortanix-unknown-sgx/lib" "~/projects/rust-sgx/hello/ring/target/x86_64-fortanix-unknown-sgx/release/deps/quic_tests-60cfc7f9614a1667.quic_tests.bo3mv8ta-cgu.0.rcgu.o" "-o" "~/projects/rust-sgx/hello/ring/target/x86_64-fortanix-unknown-sgx/release/deps/quic_tests-60cfc7f9614a1667" "-Wl,--gc-sections" "-pie" "-Wl,-O1" "-nodefaultlibs" "-L" "~/projects/rust-sgx/hello/ring/target/x86_64-fortanix-unknown-sgx/release/deps" "-L" "~/projects/rust-sgx/hello/ring/target/release/deps" "-L" "~/projects/rust-sgx/hello/ring/target/x86_64-fortanix-unknown-sgx/release/build/ring-9f5b619728470617/out" "-L" "~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-fortanix-unknown-sgx/lib" "-Wl,-Bstatic" "/tmp/rustchwXbIV/libring-5d3d20b089bc71bf.rlib" "/tmp/rustchwXbIV/libbacktrace_sys-6741d64f34191261.rlib" "~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-fortanix-unknown-sgx/lib/libcompiler_builtins-c8174d577f7ebb97.rlib" "-Wl,-Bdynamic" "~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-fortanix-unknown-sgx/lib/libunwind.a"
  = note: ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-fortanix-unknown-sgx/lib/libunwind.a(UnwindRustSgx.c.o):UnwindRustSgx.c:function libuw_malloc: error: undefined reference to '__rust_alloc'
          ~/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-fortanix-unknown-sgx/lib/libunwind.a(UnwindRustSgx.c.o):UnwindRustSgx.c:function libuw_free: error: undefined reference to '__rust_dealloc'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: Could not compile `ring`.

To learn more, run the command again with --verbose.

But without LTO:

ring$ cargo +nightly rustc --test quic_tests --release --target=x86_64-fortanix-unknown-sgx -- -C lto=no
   Compiling ring v0.14.2 (~/projects/rust-sgx/hello/ring)
    Finished release [optimized] target(s) in 0.59s

sgx-detect: RunEnclaveProdWl should use wl-signed report-test

`ioctl` has been yanked.

The sgxs crate depends on the ioctl crate, but this crate has been yanked, and so one cannot execute cargo install libenclave tools && cargo install sgxs-tools.

UserBox/UserSlice need stricter bounds on `T`

T is currently allowed to be a reference. This needs to be prevented as userspace could change the pointed-to value.

Get Rocket working

https://rocket.rs

Dependencies:

• rdrand #32
• ring #30
• time #29
• num_cpus #28
• memchr #27
• Test TLS support

Enhance debugger support

It would be nice to have further integration with GDB, such as:

• AEXs are automatically detected and switched to enclave mode
• Breakpoints
• Single-stepping (TCS opt-in/RFLAGS.TF)

We should check if the GDB plugin from the Intel SGX SDK is useful, perhaps it “just works”?

Port time

https://crates.io/crates/time

Fortanix has an internal port that could be rebased

unsafe_no_drop_flag has been removed

rust-lang/rust#35764

Use a nightly before August 24, 2016 until this issue has been fixed.

Add timeout support

The following operations in std require some form of timeout support:

• TcpStream::connect_timeout
• TcpStream::set_read_timeout
• TcpStream::set_write_timeout
• thread::sleep
• thread::sleep_ms
• thread::park_timeout
• thread::park_timeout_ms
• Condvar::wait_timeout
• mpsc::Receiver::recv_timeout

Currently, the first just doesn't use a timeout, and the rest errors/panics.

The ABI currently does not support waiting a specified amount (only no wait or indefinite wait): https://docs.rs/fortanix-sgx-abi/0.1.0-rc1/fortanix_sgx_abi/struct.Usercalls.html#method.wait . It's also not clear if timeouts make sense in SGX setting, in particular: is it the case that users depend on accurate timeouts for security purposes?

Expose CFGDATA API

For example in std::os::sgx

GDB: automatically load binary at right address

Currently, when running add-symbol-file, you need to manually add the offset to the .text section. This could come from ELF instead.

libunwind: Print error if .text or .eh_frame section size is 0

Userspace heap allocation

Currently, UserBox allocates its own memory from userspace using the alloc/free usercalls. This is inefficient. Instead, there could be an allocator that uses alloc once (or as needed) to hand out allocations. Care needs to be taken to avoid storing allocation metadata in userspace.

Port num_cpus

https://crates.io/crates/num_cpus

Fortanix has an internal port that could be rebased

sgx-detect: Improve output for the case when libsgx_enclave_common is absent

Detecting SGX, this may take a minute...
✔  SGX instruction set
  ✔  CPU support
  ✔  CPU configuration
  ✔  Enclave attributes
  ✔  Enclave Page Cache
  SGX features
    ✘  SGX2  ✘  EXINFO  ✘  ENCLV  ✘  OVERSUB  
    Total EPC size: 93.5MiB
✘  Flexible launch control
  ✘  CPU support
✔  SGX system software
  ✔  SGX kernel device (/dev/isgx)
  ✘  libsgx_enclave_common                      <=== shows red, is confusing
  ✔  AESM service
  ✔  Able to launch enclaves
    ✔  Debug mode
    ✔  Production mode (Intel whitelisted)

ftxsgx-runner-cargo should never use coresident signature

The last step of ftxsgx-runner-cargo is to run the enclave. It currently uses ftxsgx-runner which uses enclave_runner::Command with all the defaults. The defaults include using EnclaveBuilder::coresident_signature and falling back to EnclaveBuilder::dummy_signature if that doesn't work. When using ftxsgx-runner-cargo it should always use a dummy signature. Two different options to go about this:

1. Copy all of ftxsgx-runner into ftxsgx-runner-cargo and make the necessary code modifications
2. Modify ftxsgx-runner to take a command-line argument to control the way the enclave is built. Then, modify ftxsgx-runner-cargo to pass that argument.

Not sure which I prefer yet.

Expose EGETKEY/EREPORT

These could be in std::arch or std::os::sgx.

sgxs: Implement Rust API guidelines

• Naming (crate aligns with Rust naming conventions)
  • Casing conforms to RFC 430 (C-CASE)
  • Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
  • Getter names follow Rust convention (C-GETTER)
  • Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
  • Iterator type names match the methods that produce them (C-ITER-TY)
  • Feature names are free of placeholder words (C-FEATURE)
  • Names use a consistent word order (C-WORD-ORDER)
• Interoperability (crate interacts nicely with other library functionality)
  • Types eagerly implement common traits (C-COMMON-TRAITS)
    • Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
      Display, Default
  • Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
  • Collections implement FromIterator and Extend (C-COLLECT)
  • Data structures implement Serde's Serialize, Deserialize (C-SERDE)
  • Types are Send and Sync where possible (C-SEND-SYNC)
  • Error types are meaningful and well-behaved (C-GOOD-ERR)
  • Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
  • Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)
• Macros (crate presents well-behaved macros)
  • Input syntax is evocative of the output (C-EVOCATIVE)
  • Macros compose well with attributes (C-MACRO-ATTR)
  • Item macros work anywhere that items are allowed (C-ANYWHERE)
  • Item macros support visibility specifiers (C-MACRO-VIS)
  • Type fragments are flexible (C-MACRO-TY)
• Documentation (crate is abundantly documented)
  • Crate level docs are thorough and include examples (C-CRATE-DOC)
  • All items have a rustdoc example (C-EXAMPLE)
  • Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
  • Function docs include error, panic, and safety considerations (C-FAILURE)
  • Prose contains hyperlinks to relevant things (C-LINK)
  • Cargo.toml includes all common metadata (C-METADATA)
    • authors, description, license, homepage, documentation, repository,
      readme, keywords, categories
  • Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
  • Release notes document all significant changes (C-RELNOTES)
  • Rustdoc does not show unhelpful implementation details (C-HIDDEN)
• Predictability (crate enables legible code that acts how it looks)
  • Smart pointers do not add inherent methods (C-SMART-PTR)
  • Conversions live on the most specific type involved (C-CONV-SPECIFIC)
  • Functions with a clear receiver are methods (C-METHOD)
  • Functions do not take out-parameters (C-NO-OUT)
  • Operator overloads are unsurprising (C-OVERLOAD)
  • Only smart pointers implement Deref and DerefMut (C-DEREF)
  • Constructors are static, inherent methods (C-CTOR)
• Flexibility (crate supports diverse real-world use cases)
  • Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
  • Caller decides where to copy and place data (C-CALLER-CONTROL)
  • Functions minimize assumptions about parameters by using generics (C-GENERIC)
  • Traits are object-safe if they may be useful as a trait object (C-OBJECT)
• Type safety (crate leverages the type system effectively)
  • Newtypes provide static distinctions (C-NEWTYPE)
  • Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
  • Types for a set of flags are bitflags, not enums (C-BITFLAG)
  • Builders enable construction of complex values (C-BUILDER)
• Dependability (crate is unlikely to do the wrong thing)
  • Functions validate their arguments (C-VALIDATE)
  • Destructors never fail (C-DTOR-FAIL)
  • Destructors that may block have alternatives (C-DTOR-BLOCK)
• Debuggability (crate is conducive to easy debugging)
  • All public types implement Debug (C-DEBUG)
  • Debug representation is never empty (C-DEBUG-NONEMPTY)
• Future proofing (crate is free to improve without breaking users' code)
  • Sealed traits protect against downstream implementations (C-SEALED)
  • Structs have private fields (C-STRUCT-PRIVATE)
  • Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
  • Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
• Necessities (to whom they matter, they really matter)
  • Public dependencies of a stable crate are stable (C-STABLE)
  • Crate and its dependencies have a permissive license (C-PERMISSIVE)

Port ring

https://crates.io/crates/ring

Add Service API to enclave-runner

Allow library users of enclave-runner to intercept connect_stream calls and connect them to a custom service.

The information of TCS

Hi, I read the WINTEL-SGX-ABI.md and it helps me a lot.
I just tried to parse the .dll file my self which is compiled (and signed) by Windows Intel SGX SDK.
The sgxmeta section is same with the structure that you explained in your document.
However, it seems that the .tls section just contains zeros .. :(

If you have any knowledge about where the TCS information is contained in the .dll file, could you please explain it to me?

Thanks a lot!

sgx-isa: Implement Rust API guidelines

• Naming (crate aligns with Rust naming conventions)
  • Casing conforms to RFC 430 (C-CASE)
  • Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
  • Getter names follow Rust convention (C-GETTER)
  • Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
  • Iterator type names match the methods that produce them (C-ITER-TY)
  • Feature names are free of placeholder words (C-FEATURE)
  • Names use a consistent word order (C-WORD-ORDER)
• Interoperability (crate interacts nicely with other library functionality)
  • Types eagerly implement common traits (C-COMMON-TRAITS)
    • Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
      Display, Default
  • Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
  • Collections implement FromIterator and Extend (C-COLLECT)
  • Data structures implement Serde's Serialize, Deserialize (C-SERDE)
  • Types are Send and Sync where possible (C-SEND-SYNC)
  • Error types are meaningful and well-behaved (C-GOOD-ERR)
  • Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
  • Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)
• Macros (crate presents well-behaved macros)
  • Input syntax is evocative of the output (C-EVOCATIVE)
  • Macros compose well with attributes (C-MACRO-ATTR)
  • Item macros work anywhere that items are allowed (C-ANYWHERE)
  • Item macros support visibility specifiers (C-MACRO-VIS)
  • Type fragments are flexible (C-MACRO-TY)
• Documentation (crate is abundantly documented)
  • Crate level docs are thorough and include examples (C-CRATE-DOC)
  • All items have a rustdoc example (C-EXAMPLE)
  • Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
  • Function docs include error, panic, and safety considerations (C-FAILURE)
  • Prose contains hyperlinks to relevant things (C-LINK)
  • Cargo.toml includes all common metadata (C-METADATA)
    • authors, description, license, homepage, documentation, repository,
      readme, keywords, categories
  • Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
  • Release notes document all significant changes (C-RELNOTES)
  • Rustdoc does not show unhelpful implementation details (C-HIDDEN)
• Predictability (crate enables legible code that acts how it looks)
  • Smart pointers do not add inherent methods (C-SMART-PTR)
  • Conversions live on the most specific type involved (C-CONV-SPECIFIC)
  • Functions with a clear receiver are methods (C-METHOD)
  • Functions do not take out-parameters (C-NO-OUT)
  • Operator overloads are unsurprising (C-OVERLOAD)
  • Only smart pointers implement Deref and DerefMut (C-DEREF)
  • Constructors are static, inherent methods (C-CTOR)
• Flexibility (crate supports diverse real-world use cases)
  • Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
  • Caller decides where to copy and place data (C-CALLER-CONTROL)
  • Functions minimize assumptions about parameters by using generics (C-GENERIC)
  • Traits are object-safe if they may be useful as a trait object (C-OBJECT)
• Type safety (crate leverages the type system effectively)
  • Newtypes provide static distinctions (C-NEWTYPE)
  • Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
  • Types for a set of flags are bitflags, not enums (C-BITFLAG)
  • Builders enable construction of complex values (C-BUILDER)
• Dependability (crate is unlikely to do the wrong thing)
  • Functions validate their arguments (C-VALIDATE)
  • Destructors never fail (C-DTOR-FAIL)
  • Destructors that may block have alternatives (C-DTOR-BLOCK)
• Debuggability (crate is conducive to easy debugging)
  • All public types implement Debug (C-DEBUG)
  • Debug representation is never empty (C-DEBUG-NONEMPTY)
• Future proofing (crate is free to improve without breaking users' code)
  • Sealed traits protect against downstream implementations (C-SEALED)
  • Structs have private fields (C-STRUCT-PRIVATE)
  • Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
  • Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
• Necessities (to whom they matter, they really matter)
  • Public dependencies of a stable crate are stable (C-STABLE)
  • Crate and its dependencies have a permissive license (C-PERMISSIVE)

Unwinding improvements

When panicking with unwinding, the stack gets unwound before the enclave returns to userspace. This is annoying because setting breakpoints isn't really possible yet so there is no way to inspect the stack at the panic location. Unwinding will only happen if there's a catchpoint on the stack. If there isn't, an abort will be triggered. We can inspect the stack after an abort. main/thread::spawn call catch_unwind internally in rt.rs and thread/mod.rs. We could add logic such that catch_unwind is elided in some cases depending on the enclave configuration (e.g. DEBUG global).

Support running Rust unit tests

Currently, unit tests can't be compiled or run for the x86_64-fortanix-unknown-sgx target.

There are several steps to running the tests.

1. Compiling the test crate for this target
2. Compiling the crate-under-test (with cargo test)
3. Converting the build product (probably some ELF file) to SGXS
4. Running the enclave

Steps 3 & 4 can maybe be done using the runner configuration in Cargo.

Upgrade platform support to tier 2

Add a dist builder. You'd want to add the relevant target triple to https://github.com/rust-lang/rust/blob/master/src/ci/docker/dist-various-2/Dockerfile#L67. You can run it via ./src/ci/docker/run.sh dist-various-2

Improve std::is_x86_feature_detected in SGX

Currently, features not enabled at compile-time are considered disabled because CPUID doesn't work. See rust-lang/stdarch#598.

Consider datagram networking (UDP)

Currently, the Fortanix SGX ABI only supports stream networking. This is sufficient for most use cases. No decision has been made whether to add datagram networking in the future or not. Some things to consider:

• What part of the BSD sockets API is necessary to support datagram networking? How does the Fortanix SGX ABI need to be expanded?
• Does datagram networking have a big enough role to play in microservices/distributed systems?
• Are there sufficient options to securely use datagram networking (DTLS?)?
• Is the added complexity worth it?
• Can it be implemented instead as a userspace service that is accessed via a stream?

sgxs-loaders: Implement Rust API guidelines

• Naming (crate aligns with Rust naming conventions)
  • Casing conforms to RFC 430 (C-CASE)
  • Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
  • Getter names follow Rust convention (C-GETTER)
  • Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)
  • Iterator type names match the methods that produce them (C-ITER-TY)
  • Feature names are free of placeholder words (C-FEATURE)
  • Names use a consistent word order (C-WORD-ORDER)
• Interoperability (crate interacts nicely with other library functionality)
  • Types eagerly implement common traits (C-COMMON-TRAITS)
    • Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
      Display, Default
  • Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
  • Collections implement FromIterator and Extend (C-COLLECT)
  • Data structures implement Serde's Serialize, Deserialize (C-SERDE)
  • Types are Send and Sync where possible (C-SEND-SYNC)
  • Error types are meaningful and well-behaved (C-GOOD-ERR)
  • Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
  • Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)
• Macros (crate presents well-behaved macros)
  • Input syntax is evocative of the output (C-EVOCATIVE)
  • Macros compose well with attributes (C-MACRO-ATTR)
  • Item macros work anywhere that items are allowed (C-ANYWHERE)
  • Item macros support visibility specifiers (C-MACRO-VIS)
  • Type fragments are flexible (C-MACRO-TY)
• Documentation (crate is abundantly documented)
  • Crate level docs are thorough and include examples (C-CRATE-DOC)
  • All items have a rustdoc example (C-EXAMPLE)
  • Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
  • Function docs include error, panic, and safety considerations (C-FAILURE)
  • Prose contains hyperlinks to relevant things (C-LINK)
  • Cargo.toml includes all common metadata (C-METADATA)
    • authors, description, license, homepage, documentation, repository,
      readme, keywords, categories
  • Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
  • Release notes document all significant changes (C-RELNOTES)
  • Rustdoc does not show unhelpful implementation details (C-HIDDEN)
• Predictability (crate enables legible code that acts how it looks)
  • Smart pointers do not add inherent methods (C-SMART-PTR)
  • Conversions live on the most specific type involved (C-CONV-SPECIFIC)
  • Functions with a clear receiver are methods (C-METHOD)
  • Functions do not take out-parameters (C-NO-OUT)
  • Operator overloads are unsurprising (C-OVERLOAD)
  • Only smart pointers implement Deref and DerefMut (C-DEREF)
  • Constructors are static, inherent methods (C-CTOR)
• Flexibility (crate supports diverse real-world use cases)
  • Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
  • Caller decides where to copy and place data (C-CALLER-CONTROL)
  • Functions minimize assumptions about parameters by using generics (C-GENERIC)
  • Traits are object-safe if they may be useful as a trait object (C-OBJECT)
• Type safety (crate leverages the type system effectively)
  • Newtypes provide static distinctions (C-NEWTYPE)
  • Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
  • Types for a set of flags are bitflags, not enums (C-BITFLAG)
  • Builders enable construction of complex values (C-BUILDER)
• Dependability (crate is unlikely to do the wrong thing)
  • Functions validate their arguments (C-VALIDATE)
  • Destructors never fail (C-DTOR-FAIL)
  • Destructors that may block have alternatives (C-DTOR-BLOCK)
• Debuggability (crate is conducive to easy debugging)
  • All public types implement Debug (C-DEBUG)
  • Debug representation is never empty (C-DEBUG-NONEMPTY)
• Future proofing (crate is free to improve without breaking users' code)
  • Sealed traits protect against downstream implementations (C-SEALED)
  • Structs have private fields (C-STRUCT-PRIVATE)
  • Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
  • Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
• Necessities (to whom they matter, they really matter)
  • Public dependencies of a stable crate are stable (C-STABLE)
  • Crate and its dependencies have a permissive license (C-PERMISSIVE)

Port rand

https://crates.io/crates/rand

Investigate non-constant time properties of AES-CMAC implementation

Deriving the subkeys K1/K2 is currently not constant time.

Unwinding support

Implement unwinding support for x86_64-fortanix-unknown-sgx.

How to use (Linux)

This issue documents the current best way to build for x86_64-fortanix-unknown-sgx and run the enclaves on Linux. Subscribe to this issue to be notified of changes.

Installing build dependencies

Install Rust nightly

You will need Rust nightly installed, the easiest way is with rustup:

rustup default nightly

Building

Run Cargo

Build your crate for the x86_64-fortanix-unknown-sgx target, for example:

cargo build --target x86_64-fortanix-unknown-sgx

or

cargo test --target x86_64-fortanix-unknown-sgx --no-run

Installing runtime dependencies

Install SGX driver & software

Install SGX pre-requisites. In order to test execution, you'll need to have a CPU with Intel SGX support. SGX support needs to be enabled in the BIOS. You'll also need to install the SGX driver and Platform Software (PSW) from Intel.

Install enclave conversion utilities & runtime

cargo install sgxs-tools --version 0.6.0-rc1
cargo install fortanix-sgx-tools --git https://github.com/fortanix/rust-sgx

Running

To run any binary $BINARY (you can find these in target/x86_64-fortanix-unknown-sgx/debug after building), do:

ftxsgx-elf2sgxs $BINARY --debug --threads 1 --heap-size 0x20000 --ssaframesize 1 --stack-size 0x20000
sgxs-append -i $BINARY.sgxs
ftxsgx-runner $BINARY.sgxs

Depending on your application, you might want to increase the stack or heap size or the number of threads.

cargo build-enclave core_io issue

Hello,

cargo build-enclave -H 0x1000 -S 0x1000
gives

compiling core_io v0.1.20161028
error: failed to run custom build command for `core_io v0.1.20161028`
process didn't exit successfully: `/root/hassan/trusted/target/debug/build/core_io-e6c2a034de9ce8b9/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unknown compiler version, upgrade core_io?', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/option.rs:785
note: Run with `RUST_BACKTRACE=1` for a backtrace.

ERROR: There was an error executing `cargo rustc': Process exited with exit code: 101

Any ideas how to fix this?

Thank you.

sgx-detect: Incorrect help message with AESM not installed

sudo ./sgx-detect --verbose
[sudo] password for administrator: 
Detecting SGX, this may take a minute...
✔  SGX instruction set
  ✔  CPU support
  ✔  CPU configuration
  ✔  Enclave attributes
  ✔  Enclave Page Cache
  SGX features
    ✘  SGX2  ✘  EXINFO  ✘  ENCLV  ✘  OVERSUB  
    Total EPC size: 93.5MiB
✘  Flexible launch control
  ✔  CPU support
  ✔  CPU configuration
  ✘  Able to launch production mode enclave
✘  SGX system software
  ✔  SGX kernel device (/dev/isgx)
  ✘  libsgx_enclave_common
  ✘  AESM service
  ✘  Able to launch enclaves
    ✘  Debug mode

🕮  SGX system software > AESM service
AESM could not be contacted. AESM is needed for launching enclaves and generating attestations.

Please check your AESM installation.

debug: error communicating with aesm
debug: cause: error communicating with aesm
debug: cause: Connection refused (os error 111)

More information: https://edp.fortanix.com/sgx-detect/errors#aesm-service

🕮  SGX system software > Able to launch enclaves > Debug mode
The enclave could not be launched.

debug: failed to load report enclave
debug: cause: failed to load report enclave
debug: cause: Failed to call EINIT.
debug: cause: The SGX instruction returned an error: InvalidEinitToken.

More information: https://edp.fortanix.com/sgx-detect/errors#run-enclave-debug

When does "connection refused" happen?

Prevent floating-point/vector registers from leaking state

Port memchr

https://crates.io/crates/memchr

Support Clang & cc

When using the cc crate (in e.g. a build script) targeting x86_64-fortanix-unknown-sgx, and using Clang as the compiler, --target=x86_64-fortanix-unknown-sgx is inserted. This of course doesn't work because clang doesn't know this target.

Possible fixes?

• Should we reuse llvm_target from rustc target spec? (unstable)
• Just patch cc to known to pass linux?

Add Windows support

• Implement a loader with the Windows Enclave API in the sgxs-loaders crate
• Implement AesmClient for Windows (https://github.com/Microsoft/openenclave/blob/master/host/sgx/windows/aesm.c)
• Modify ftxsgx-runner to use OS-dependent loader
• Enable building enclaves on Windows

Port rdrand

https://crates.io/crates/rdrand
nagisa/rust_rdrand#5

Stack probes

Enable stack probes for x86_64-fortanix-unknown-sgx target.

sgx-detect: Failed to run prod enclave with FLC on Xeon E

sudo ./sgx-detect --verbose
Detecting SGX, this may take a minute...
✔  SGX instruction set
  ✔  CPU support
  ✔  CPU configuration
  ✔  Enclave attributes
  ✔  Enclave Page Cache
  SGX features
    ✘  SGX2  ✘  EXINFO  ✘  ENCLV  ✘  OVERSUB  
    Total EPC size: 93.5MiB
✘  Flexible launch control
  ✔  CPU support
  ✔  CPU configuration
  ✘  Able to launch production mode enclave
✔  SGX system software
  ✔  SGX kernel device (/dev/isgx)
  ✘  libsgx_enclave_common
  ✔  AESM service
  ✔  Able to launch enclaves
    ✔  Debug mode
    ✘  Production mode
    ✔  Production mode (Intel whitelisted)

🕮  SGX system software > Able to launch enclaves > Production mode
The enclave could not be launched. This might indicate a problem with FLC.

debug: failed to load report enclave
debug: cause: failed to load report enclave
debug: cause: The EINITTOKEN provider didn't provide a token
debug: cause: aesm error code GetLicensetokenError_6

More information: https://edp.fortanix.com/sgx-detect/errors#run-enclave-prod

Port rustc-serialize

https://crates.io/crates/rustc-serialize