apache / incubator-teaclave-sgx-sdk

Apache Teaclave (incubating) SGX SDK helps developers to write Intel SGX applications in the Rust programming language, and also known as Rust SGX SDK.
https://teaclave.apache.org
Apache License 2.0
1.17k stars 259 forks source link

v2.0.0-preview: crate 'cpufeatures' failed detect 'target_env = "sgx"' #401

Open ChuanDou2021 opened 2 years ago

ChuanDou2021 commented 2 years ago

I built a demo to calc Sha256,but got Illegal instruction (core dumped). The Sha256 comes from crate sha2.

cd samplecode/helloworld
BUILD_STD=cargo make
cd bin
./app

[+] Init Enclave Successful 2!
This is a normal world string passed into Enclave!
target_env = not sgx
Illegal instruction (core dumped)

After some research,I found crate cpufeatures which sha2's dependent library failed detect target_env = "sgx", cpufeatures uses cpuid to check cpu features, then crash.

And I found the file x86_64-unknown-linux-sgx.json, assign env the value gnu , than's the problem, if I change env value from gnu to sgx, it's ok.

[+] Init Enclave Successful 2!
This is a normal world string passed into Enclave!
target_env = sgx
This is a in-Enclave Rust string!
[+] ECall Success...

My question is: should I keep sgx value in x86_64-unknown-linux-sgx.json?

This is my demo codes:

diff --git a/samplecode/helloworld/enclave/Cargo.toml b/samplecode/helloworld/enclave/Cargo.toml
index 40d61163..81b6301a 100644
--- a/samplecode/helloworld/enclave/Cargo.toml
+++ b/samplecode/helloworld/enclave/Cargo.toml
@@ -31,3 +31,7 @@ default = []
 [target.'cfg(not(target_vendor = "teaclave"))'.dependencies]
 sgx_types = { path = "../../../sgx_types" }
 sgx_tstd = { path = "../../../sgx_tstd" }
+
+[dependencies]
+sha2 = "0.10.2"
+hex-literal = "0.3.4"
diff --git a/samplecode/helloworld/enclave/src/lib.rs b/samplecode/helloworld/enclave/src/lib.rs
index 5fd6daf4..66984701 100644
--- a/samplecode/helloworld/enclave/src/lib.rs
+++ b/samplecode/helloworld/enclave/src/lib.rs
@@ -29,6 +29,9 @@ use std::slice;
 use std::string::String;
 use std::vec::Vec;

+use hex_literal::hex;
+use sha2::{Digest, Sha256, Sha512};
+
 /// # Safety
 #[no_mangle]
 pub unsafe extern "C" fn say_something(some_string: *const u8, some_len: usize) -> SgxStatus {
@@ -53,6 +56,28 @@ pub unsafe extern "C" fn say_something(some_string: *const u8, some_len: usize)
     // Rust style convertion
     hello_string += String::from_utf8(word_vec).expect("Invalid UTF-8").as_str();

+    let target_env = {
+        let mut s = String::new();
+
+        #[cfg(not(target_env = "sgx"))]
+        s.push_str("not sgx");
+
+        #[cfg(target_env = "sgx")]
+        s.push_str("sgx");
+
+        s
+    };
+    println!("target_env = {}", target_env);
+
+    let mut hasher = Sha256::new();
+    // write input message
+    hasher.update(b"hello world");
+    let result = hasher.finalize();
+    assert_eq!(
+        result[..],
+        hex!("b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9")[..]
+    );
+
     // Ocall to normal world for output
     println!("{}", &hello_string);

Thanks.

volcano0dr commented 2 years ago

In your example, assigning the value of env to sgx dose work, but in some crates that depend on libc, it may cause the detection target_env to fail. For the processing of the CPUID instruction, you can refer to the example code httpreq.

qinkunbao commented 2 years ago

In your example, assigning the value of env to sgx dose work, but in some crates that depend on libc, it may cause the detection target_env to fail. For the processing of the CPUID instruction, you can refer to the example code httpreq.

Retrieving "CPUID" information through ocalls without sanitizing checking could be dangerous, especially for crypto libraries. https://github.com/gramineproject/graphene/issues/966

ChuanDou2021 commented 2 years ago

but in some crates that depend on libc, it may cause the detection target_env to fail.

I see, seems no perfect solution for the problem, thanks for you reply