Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cpuid not supported in sgx environment #183

Closed
wants to merge 1 commit into from

Conversation

yihuang
Copy link

@yihuang yihuang commented Jul 14, 2020

cpuid is not supported in sgx environment.

@yihuang yihuang changed the title don't use cpuid-bool in fortanix sgx target cpuid not supported in sgx environment Jul 14, 2020
@yihuang yihuang force-pushed the master branch 5 times, most recently from 2f373a8 to 49b786d Compare July 14, 2020 07:53
@newpavlov
Copy link
Member

newpavlov commented Jul 14, 2020

Thank you for reporting it! But this approach will mean that it will not be possible to enable HW acceleration via compiler flags. I think it will be better to modify the cpuid-bool crate instead (e.g. on SGX return false if at least on of requested target-features was not enabled).

@jethrogb
Copy link

My recommendation is to always use is_x86_feature_detected and to fall back to a local definition in case std is not available.

#[cfg(not(feature = "std"))]
macro_rules! is_x86_feature_detected {
    ($feat:literal) => {
        {
            #[cfg(all(target_vendor="fortanix", target_env="sgx"))] {
                cfg!(target_feature = $feat)
            }
            #[cfg(not(all(target_vendor="fortanix", target_env="sgx")))] {
                cpuid_bool::cpuid_bool!($feat)
            }
        }
    };
}

@newpavlov
Copy link
Member

I've published cpuid-bool v0.1.1 which should fix this issue. Can you please do cargo update and check if SHA crates work correctly?

@jethrogb
Copy link

That's not sufficient. You should call is_x86_feature_detected when available.

@newpavlov
Copy link
Member

@jethrogb
I think it's unnecessary complication at this stage. I don't want to repeat this code in all crates which will depend on cpuid-bool. Plus note that cpuid-bool works a bit differently from is_x86_feature_detected, it caches a boolean result, instead of two u64s, so it's a bit more efficient, since it does not have to recompute flag each time. For SHA crates it does not matter that much, but I think it will be noticeable for AES.

@jethrogb
Copy link

jethrogb commented Jul 14, 2020

I don't want to repeat this code in all crates which will depend on cpuid-bool.

You'll have to. As mentioned previously, CPUID is not supported on some platforms and as such those platforms can't be supported by cpuid_bool. The standard way for Rust platforms to advertise x86 CPU features is std::is_x86_feature_detected. On some platforms this macro may be implemented by CPUID, but on others it can work differently. The only cross-platform way to know whether a feature is enabled is with the macro in std which properly abstracts all the platform differences.

@newpavlov
Copy link
Member

newpavlov commented Jul 14, 2020

What are other x86 targets apart from SGX which do not support CPUID instruction? In your snippet you special-case SGX as well, so I don't see why I have to use is_x86_feature_detected in the current form, while cpuid-bool works without issues and results in a simpler code.

@jethrogb
Copy link

In your snippet you special-case SGX as well

I'm only special-casing it in the case std::is_x86_feature_detected is not available. This is no longer necessary with your recent change to cpuid-bool:

#[cfg(not(feature = "std"))]
macro_rules! is_x86_feature_detected {
    ($feat:literal) => {
        cpuid_bool::cpuid_bool!($feat)
    };
}

I don't see why I have to use is_x86_feature_detected in the current form, while cpuid-bool will work without issues.

cpuid-bool won't work because it can't work.

@newpavlov
Copy link
Member

newpavlov commented Jul 14, 2020

cpuid-bool won't work because it can't work.

What? Can you please elaborate? is_x86_feature_detectedis not magic, under the hood it uses code very similar to one used in cpuid-bool.

@jethrogb
Copy link

jethrogb commented Jul 14, 2020

I feel like I'm repeating myself here. cpuid-bool uses the CPUID instruction so it can't work on platforms that don't support it.

is_x86_feature_detected is not magic, under the hood it uses code very similar to one used in cpuid-bool.

It is, in a way, “magic” as the platform is free to change the implementation of is_x86_feature_detected to provide accurate information regardless of how the information is obtained.

And I will repeat my earlier question: what are other x86 targets apart from SGX which do not support CPUID instruction?

I don't know.

@tarcieri
Copy link
Member

@jethrogb if I'm understanding right, it sounds like the issue is the Fortanix Rust target (x86_64-fortanix-unknown-sgx) includes a special std implementation with a custom std::is_x86_feature_detected which works correctly inside SGX enclaves. Is that the case?

@jethrogb
Copy link

It doesn't today but it likely will in the future.

@newpavlov
Copy link
Member

I guess when the Fortranix target will add a custom implementation of the is_x86_feature_detected macro, we could add std feature to cpuid-bool, which would use this macro instead of the custom CPUID-based code. Until then I think we can keep things as-is. But ideally I would prefer for something like RFC 2725 to land, since we need this feature on ARM as well (right now we have to depend on libc).

@newpavlov
Copy link
Member

Should be fixed in RustCrypto/utils#68.

We can revisit this problem when Fortranix target will introduce custom is_x86_feature_detected implementation.

@newpavlov newpavlov closed this Aug 6, 2020
@jethrogb
Copy link

jethrogb commented Aug 6, 2020

Why not fix it now? By not fixing it now, you're forcing people to have to deal with this (i.e. updating their dependencies) in the future.

@newpavlov
Copy link
Member

newpavlov commented Aug 6, 2020

Because for the current state of things the problem is "fixed". It is quite possible that before the custom macro implementation we will get rust-lang/rfcs#2725 merged and implemented, so I don't want to make code more complex than necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants