Hello,
During our tests, we encountered a strange error message from the enclave. We
were expecting an error message containing "Destination address required" (the
error message for errno 89 on Linux/Ubuntu) but got "Identifier removed (os
error: 89)" instead.
After digging a little in the implementation, we found the following snippet in
`sgx_tstd/src/io/error.rs` :
```
impl fmt::Display for Error {
fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
match self.repr {
Repr::Os(code) => {
let detail = sys::os::error_string(code);
write!(fmt, "{} (os error: {})", detail, code)
}
Repr::Custom(ref c) => c.error.fmt(fmt),
Repr::Simple(kind) => write!(fmt, "{}", kind.as_str()),
Repr::SgxStatus(status) => {
let detail = status.__description();
write!(fmt, "{} (sgx error: {})", detail, status)
}
}
}
}
```
It turns out that the Os error display uses the `error_string` function which
in turn calls `strerror_r` (declared as an external function in sgx_libc).
`strerror_r` is part of the tlibc library from the Intel Linux SGX SDK and is
responsible for this bug because it uses a hardcoded list of error messages
defined there:
https://github.com/intel/linux-sgx/blob/56faf11a455b06fedd6adc3e60b71f6faf05dc0f/sdk/tlibc/gen/errlist.c
The list comes from OpenBSD but not all OS have the same error code - error
message mapping. In our case, we ran our enclave on an Ubuntu system but got
the error message for errno 89 as if we were on OpenBSD!
We can think of several ways to fix this issue.
A first approach would be to open an issue in the Intel Linux SGX
SDK(https://github.com/intel/linux-sgx) repository so that the `strerror_r`
function from Intel SGX SDK returns the appropriate error messages for all OS.
Another (more practical ?) solution would be to address the issue directly in
the teaclave sgx sdk. We could implement `strerror_r` in teaclave using an
OCALL to the `strerror_r` of the host OS. If performance matters, one might
also want to cache the error message, or even better prefetch them at enclave
initialization.
What do you think is the best approach to take?
Best regards,
Huu Tan Mai, Corentin Lauverjat @ Mithril Security
--
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/issues/354
