std::sys::os::error_string returns the wrong error messages

[clauverjat]

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

[volcano0dr]

I think the first approach is better.