cpufeatures: support freestanding/UEFI x86 targets

[rvolosatovs]

This fixes compilation of dependent crates for these targets.

For example, sha2:

Before:

$ cargo build --target x86_64-unknown-none --no-default-features
   Compiling sha2 v0.10.6 (/home/rvolosatovs/src/github.com/rustcrypto/hashes/sha2)
LLVM ERROR: Do not know how to split the result of this operator!

error: could not compile `sha2`
$ cargo build --target x86_64-unknown-uefi --no-default-features
   Compiling sha2 v0.10.6 (/home/rvolosatovs/src/github.com/rustcrypto/hashes/sha2)
LLVM ERROR: Do not know how to split the result of this operator!

error: could not compile `sha2`

After:

$ cargo build --target x86_64-unknown-none --no-default-features
   Compiling cpufeatures v0.2.5 (/home/rvolosatovs/src/github.com/rustcrypto/utils/cpufeatures)
   Compiling sha2 v0.10.6 (/home/rvolosatovs/src/github.com/rustcrypto/hashes/sha2)
    Finished dev [optimized + debuginfo] target(s) in 0.19s
$ cargo build --target x86_64-unknown-uefi --no-default-features
   Compiling cpufeatures v0.2.5 (/home/rvolosatovs/src/github.com/rustcrypto/utils/cpufeatures)
   Compiling sha2 v0.10.6 (/home/rvolosatovs/src/github.com/rustcrypto/hashes/sha2)
    Finished dev [optimized + debuginfo] target(s) in 0.19s

[newpavlov]

I am not sure it's a correct approach. The problem is not with the CPUID instruction. Both none and uefi targets handle it just fine. For reference, Rust's std also assumes that CPUID is available on all non-SGX x86-64 targets.

The issue is caused by the SHA instructions. To me it looks like an LLVM issue. Have you tried to look into it?

For now, you can use the force-soft feature as a temporary workaround.

[tarcieri]

Oh yeah, interesting... for some reason I thought UEFI didn't have access to CPUID but that seems to be wrong and there are ample resources that describe calling CPUID from UEFI

[rvolosatovs]

Thanks, I'll look into LLVM issue

[tarcieri]

It seems people are still hitting this, even with the force-soft feature of sha2 enabled, and even with the force soft cfg attributes for all of the other crates enabled:

RustCrypto/SSH#91

I think we should really try to get a workaround for this added. We've had dozens of reports and it causes very confusing errors.

[yaoxin1995]

I want to use this ssh-key in no_std environment.

However, I got the error LLVM ERROR: Do not know how to split the result of this operator!.

How I add this crate:

ssh-key  = {version = "0.5.1", default-features = false, features = ["alloc", "ecdsa", "ed25519", "p384"]}

I already add sha2 with feature force-soft enabled:

sha2 = { version = "0.10.6", default-features = false,  features = ["force-soft"]}

Target information in file x86_64-qkernel.json:

{
  "llvm-target": "x86_64-unknown-none",
  "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128",
  "linker-flavor": "gcc",
  "target-endian": "little",
  "target-pointer-width": "64",
  "target-c-int-width": "32",
  "arch": "x86_64",
  "os": "none",
  "disable-redzone": true,
  "features": "-mmx,-avx,-sse,+soft-float",
  "frame-pointer": "always"
}

How I compile the project:

RUSTFLAGS="--cfg aes_force_soft --cfg polyval_force_soft --cfg log" CARGO_TARGET_DIR=../target cargo xbuild --target x86_64-qkernel.json --release --verbose

Do you know how to solve it?

[tarcieri]

@yaoxin1995 in theory this PR will solve it. Perhaps you could test it out?

Add the following to your Cargo.toml:

[patch.crates-io.cpufeatures]
git = "https://github.com/rvolosatovs/utils.git"
branch = "freestanding-uefi"