Teaclave rebuilt Intel's SGX SDK in Rust and kept the enclave model intact

Intel's SGX SDK was C, and this is a rewrite of it in Rust

The problem this project addresses is a language mismatch. Code that runs inside your trusted boundary carries the same memory safety risks as any other code unless the language rules them out. The stated purpose of the project is to let developers write Intel SGX applications in Rust, with the safety and performance benefits of the Rust programming language. The README is direct about the scale of the work: the v2.0 line is described as a refactoring of Intel's SGX SDK using Rust that requires only a minimal portion of Intel's original SDK. The audience is therefore specific: security engineers and systems programmers who need SGX enclaves and would rather not write that code without Rust's safety guarantees, and who are willing to accept a build system and dependency model that differ from the C original.

Three build modes, and picking the wrong one costs you a rebuild

The SDK supports three build modes, and the README lists them explicitly. The default is the std-aware cargo build, selected with the BUILD_STD environment variable set to cargo. The traditional no_std cargo build is selected with BUILD_STD=no and gives the minimal footprint. The third is BUILD_STD=xargo, which uses xargo build with a customized sysroot. The relevant cargo commands themselves are ordinary ones:

cargo build
xargo build

and the mode itself is a single environment variable:

BUILD_STD=cargo
BUILD_STD=no
BUILD_STD=xargo

This is the first real decision a new user has to make, and it interacts with everything else. The no_std route means you write against the SDK's own standard library rather than Rust's, and the xargo route exists for the cases where a customized sysroot is needed. Because the mode is baked into the build rather than into the source, changing it later means rebuilding the dependency tree, so it is worth deciding on the first day rather than the first bug.

Tokio and Tonic run inside the enclave without modification

The claim that most distinguishes this SDK from a Rust wrapper around Intel's original SDK is ecosystem compatibility. The README states direct support for Tokio and Tonic in enclave programming without modifications. In practice that means an enclave can host an async runtime and serve RPC, rather than being limited to a synchronous callback style. The standard library, sgx_tstd, is described as well tested and part of a comprehensive testing framework, and the project is careful to mention that the testing story is part of the deliverable rather than an afterthought. Another stated benefit is simplified dependencies: the v2.0 line eliminates the need to maintain more than one hundred third-party dependencies, and most Rust crates are expected to work without modification. That last point is the practical unlock, because the usual reason a project cannot be moved to Rust is a long tail of vendored libraries that do not compile.

The sample directory is the closest thing to an API tour

The repository does not ship a tutorial in the README, and the documentation is hosted on the project website. What the repository does ship is samplecode/, and the list is a good index of what the SDK can do. There is helloworld as the basic enclave, crypto for cryptographic operations within enclaves, seal for data sealing and unsealing, httpreq for an HTTP client inside the enclave, rpc for remote procedure calls using Tonic and Tokio, hyper-rustls-https-server for an HTTPS server built on Hyper and Rustls, backtrace for stack trace functionality, cov for code coverage analysis tools, logger for logging, regex for regular expression processing, switchless for switchless call optimization, and zlib-lazy-static-sample for compression with lazy static initialization. The top-level crate directories line up with that list, with separate directories for sgx_crypto, sgx_tseal, sgx_types, sgx_libc, sgx_macros and others. The samples are also the honest measure of coverage, because the README notes that migration of additional v1.1 samples to v2.0 is ongoing.

The crate layout separates the trusted runtime from the untrusted shim

The top-level entries give the architecture away, even without documentation. There are crates with names that map onto the standard SGX execution model: sgx_trts, sgx_urts and sgx_tstd for the trusted runtime service, the untrusted runtime service and the standard library, plus sgx_unwind for the exception path, sgx_types for the shared type definitions, and sgx_ffi for the enclave interface. Around them sit capability crates: sgx_crypto, sgx_rand, sgx_tseal, sgx_key_exchange, sgx_protected_fs, sgx_oc for the out-of-enclave calls, sgx_edl for the enclave definition and interface layer, sgx_dcap, sgx_alloc and sgx_rsrvmm for memory, sgx_serialize, sgx_sync, sgx_demangle, sgx_backtrace and sgx_macros. The SDK also carries a common/ directory, a buildenv.mk, a rust-toolchain file and a tools/ directory, and the presence of AGENTS.md and SECURITY.md says the project is set up for both agent-assisted work and coordinated disclosure.

The README says v2.0 while the release list stops at v1.0.8

The versioning here needs care, because two sources disagree in a way that matters to an adopter. The README describes v2.0 as the current version and contrasts it with the legacy v1.1 line. The published release list, on the other hand, shows v1.0.8 from 2019-06-24, v1.0.7 from 2019-05-10 and v1.0.6 from 2019-02-06, and the repository has no newer tagged release listed. The last push was on 2026-06-10, so the tree is receiving changes even though no release tag reflects them. The licence is Apache 2.0, which for an Apache project means the standard patent grant and the NOTICE file obligations, and the repository carries a LICENSE file, a NOTICE file and a licenses/ directory for third-party code. Any adoption plan should assume you are tracking the main branch rather than a tagged release, and should check which parts of v2.0 have actually landed.

Where SGX is the wrong shape of answer

The SDK is a bad fit in three situations. If you need trusted execution in general and have not committed to Intel SGX, everything here, the enclave model, the sealing model, the untrusted runtime service, is tied to one vendor's architecture, and the migration cost to a different trusted execution environment is the whole code base. If your threat model does not need a trusted boundary, the hardware requirement and the build complexity are pure overhead. And if your application needs a capability that has not been migrated from v1.1 yet, you will find yourself reading old sample code. The alternative approach worth naming is writing the enclave against Intel's original SDK and keeping Rust for the untrusted side, which is less pleasant but is the path with fewer moving parts, and it is the comparison the v2.0 rewrite is implicitly making against itself. Given that the whole project is a port, the decision hinges on whether your team is willing to own the port of any feature the v2.0 line has not yet covered.

Editorial conclusion

The Teaclave SGX SDK is the right choice for a team that needs Intel SGX enclaves and wants to write them in Rust, and the wrong choice for a team that only needs trusted execution in general, since the whole surface is tied to one vendor's instruction set and one enclave model. Before you commit, read the samplecode directory end to end rather than the README alone, because the sample set is the only API tour the repository offers, confirm that the features your application needs, in particular the ones beyond the standard library, are present in the v2.0 line rather than still in the v1.1 samples, and plan for a build environment that can produce SGX-enabled enclaves at all, since the Rust toolchain alone is not sufficient.

Frequently asked questions

Official sources

1. apache/teaclave-sgx-sdk on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases