[Feature Request] Disable SIMD with a feature

[tjhu]

Hi!

We are developing a new research OS. Even though our OS runs on x86, it currently doesn't support SIMD instructions. It would be nice if there's a feature that allows us to disable the usage of SIMD instructions and use the software implementation instead.

hashes/sha2/src/sha256.rs

Lines 153 to 157 in bb71874

	} else if #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] {
	mod soft;
	mod x86;
	use x86::compress;
	} else {

[newpavlov]

Greetings!

AFAIK SIMD instructions and feature detection on x86 do not need OS support. Can you please clarify what do you mean by lack of SIMD support?

Adding a feature for enforcing software implementation should not be hard and it also may be useful for reducing final binary size a bit.

[tarcieri]

It would probably make more sense to have a (potentially on-by-default) feature for SIMD that could be disabled, rather than taking away functionality with a "feature".

[newpavlov]

The main problem with such approach is that it becomes effectively impossible to disable this feature if the crate is used as an indirect dependency somewhere in a project dependency tree, since people often don't bother with default-features = false. So until we get some kind non-feature-based crate configurability, I think it will be better to use "disabling" features in cases like this.

[tjhu]

Thanks for the quick response!

From OSDev - SSE

To support SSE, you will need to implement separate code paths for saving and restoring SSE state.

Since SIMD support is not critical to our paper, our implementation is still in the early stages of discussion.

[newpavlov]

Note that by default Rust compiler enables SSE2 for x86-64 builds. I thought you plan to use sha2 in the kernel space, so since no one can interrupt execution of such code (well, of course there are literal hardware interrupts, but I think we can assume that they will not use SSE registers), saving and restoring registers should not matter. If we are talking about user-space applications, then until we implement this feature it should be enough to run your OS on CPU without SHA extension (which is relatively rare today). In this case the library simply will never take path which uses SHA instructions.

[tjhu]

Yes, we are using sha2 in userspace. We use custom target files to prevent the compiler from generating SSE instructions(they look something like this).

We are currently developing a userspace TPM driver that uses sha2. Rustc errors out with the message LLVM ERROR: Do not know how to split the result of this operator! when compiling the it. Our workaround is to fork sha2 and hardcode it to use software implementation regardless of the target architecture.