Improve std::is_x86_feature_detected in SGX

[jethrogb]

Currently, features not enabled at compile-time are considered disabled because CPUID doesn't work. See rust-lang/stdarch#598.

[gnzlbg]

If you compile the SGX target with -C target-feature=+avx2 and do is_x86_feature_detected!("avx2") that should return true today even though CPUID is not available.

[jethrogb]

And it does exactly that today.

[gnzlbg]

So not all features are considered disabled ;)

I don't know whether SGX can do better at run-time, do you have links to relevant documentation that I could read? If that's the case, we can improve std_detect support for SGX, either by modifying x86, or by implementing something completely different (it should be easy to do either).

Either way, it would be good to have an SGX build job in stdsimd that can run tests, so that we can easily hack on this without breaking anything.

[jethrogb]

I don't know whether SGX can do better at run-time, do you have links to relevant documentation that I could read?

There's not too much out there. Here are some approaches I'm aware of:

1. You can call XGETBV to find out XCR0, so some of the features in there may be detected this way.

2. There's “ask userspace and trust the result”. If userspace lies about a feature being available, you'll get #UD when trying to execute the relevant instruction, but userspace can always do a DoS, so no big deal...? If userspace lies about a feature not being available, this will result in slower performance. If you need the feature for security (e.g. RDRAND, AES-NI), the enclave should abort.

3. There's “try executing instructions and see if they fail”. I'm not sure if anyone is seriously considering this. Userspace can't lie about anything this way. Userspace may DoS the enclave when running the detection routine, but that seems better than DoSing later when the enclave already thinks it can do something.

[gnzlbg]

I think that for std applications we can link against that intel library (or re-implement it in Rust) for the SGX target. That sounds good enough to me (if userspace lies, then that's the way it is).

The std_detect crate can offer cargo features to select the other types of behavior, such that recompiling libstd with those enabled would change the run-time feature detection method.

[briansmith]

3. There's “try executing instructions and see if they fail”. I'm not sure if anyone is seriously considering this. Userspace can't lie about anything this way. Userspace may DoS the enclave when running the detection routine, but that seems better than DoSing later when the enclave already thinks it can do something.

Even if we accept DoS is acceptable, userspace may be reasonably lie about any bits that would affect the enclave's decisions regarding side channels. For example, userspace might lie about which microarchitecture is in use or any feature bits that indicate that a previously-safe feature isn't safe (e.g. from side channels like Spectre).

[gnzlbg]

FWIW one does not need SGX to run into these issues. In std::detect we already deal with CPUs that advertise that they support some feature, but then provide a completely buggy and broken implementation of it. That’s arguably even worse because trying to execute an instruction won’t fail, but do something else than what it should do instead (e.g. making all optimizations unsound). So at the end of the day you have to trust the hardware somewhat, user space somewhat, etc.

[jethrogb]

userspace may be reasonably lie about any bits that would affect the enclave's decisions regarding side channels.

Userspace feature detection should only be used for performance improvements. For security, you must only rely on what you know through SGX instructions/remote attestation. If the only way you can learn about side-channel protections is from userspace then you must assume the worst.

So at the end of the day you have to trust the hardware somewhat, user space somewhat, etc.

No. With SGX, you don't have to trust userspace at all for confidentiality and integrity concerns.

[gnzlbg]

No. With SGX, you don't have to trust userspace at all for confidentiality and integrity concerns.

@jethrogb: the behavior of executing an instruction that's not supported by the CPU is undefined (and we do exploit this for optimizations); this is why most hardware intrinsics are unsafe fns. If user-space (or the hardware) lies about which features are supported, then code that would have been safe to execute would have undefined behavior. I don't understand how SGX could protect you from this. Best case the code would be mis-optimized, worst case an attacker could figure out how to exploit the UB to leak data.