Thank you for your reply, they make sense a lot! > > But Enclave written in C is not taking advantage of rigorous checking of > > Rust sgx_tstd but instead relies on Intel's tlibc (and Intel does not > > provide checks on the primitive ocalls? I believe they also do?) > > I think there's one misunderstanding: Intel's tlibc does not provide any APIs > which needs ocalls. In comparison, `sgx_tstd` provides APIs which requires > ocalls (e.g., `std::net`). If someone want to use external C libraries which > needs ocalls, he cannot use `sgx_std` obviously. Then, the only thing he can > do is to write their own ocalls to extend Intel's tlibc, which may be > vulnerable [1]. >
Thanks for your correction! Yea, I originally thought tlibc provide some ocall to support some system calls. In this case, if enclave code only depends on tlibc, it won't leave the enclave. Then I guess the [current version of SQLite port](https://github.com/apache/incubator-teaclave-sgx-sdk/pull/274/commits/9cdf6c3f86b4631b51eef4802adc79e13cf36f87) won't leave enclave during execution (since I make it support in-memory database only and it currently does not introduce any additional ocalls)? Please correct me if I am wrong! > The solution I mentioned is to provide these extended libc API on top of the > ocall interfaces written in Rust which have better checking and auditing. > Hope this can explain my previous post. > > ``` > ---------------------------------------------------------------------------- > Enclave (Rust) | Enclave (C) > ----------------------+---------------+------------------------------------- > Rust standard library | extended libc | SGX platform interfaces (Rust/C FFI) > ----------------------+---------------+ > ocall interfaces (Rust) | > --------------------------------------+------------------------------------- > ``` > > * [1] > [GHSA-525h-wxcc-f66m](https://github.com/openenclave/openenclave/security/advisories/GHSA-525h-wxcc-f66m) Yes, this feels like a standard solution similar to SGX SDK solutions like Google Asylo, MS Openenclave ([link here](https://github.com/openenclave/openenclave/blob/116edfdb863c4b51cb00807ee5d416f2dfa9e3c9/include/openenclave/edl/syscall.edl)) or libOS solutions like MAYI Occlum and others. Thanks for your explanation! And I guess although this might make people recklessly port libraries, this still might be a good option to have. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-teaclave-sgx-sdk/pull/274#issuecomment-716093743
