Miscompilation under target-cpu >= haswell

[alecmocatta]

This example fails when compiled with target-cpu "haswell" or more recent:

use aes_soft::{block_cipher_trait::BlockCipher, Aes128};

fn main() {
    let plain = [127, 0, 0, 1, 174, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
    let key = [0; 16];
    let encrypted = [222, 157, 168, 71, 195, 237, 77, 237, 182, 194, 17, 235, 182, 214, 204, 80];

    let output = encrypt(plain, key);
    assert_eq!(output, encrypted);

    println!("success");
}

fn encrypt(input: [u8; 16], key: [u8; 16]) -> [u8; 16] {
    let key = key.into();
    let mut block = input.into();
    let cipher = Aes128::new(&key);
    cipher.encrypt_block(&mut block);
    block.into()
}

> RUSTFLAGS='-C target-cpu=ivybridge' cargo run --release
success
> RUSTFLAGS='-C target-cpu=haswell' cargo run --release
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `[103, 175, 2, 16, 66, 180, 192, 20, 55, 121, 111, 21, 82, 184, 106, 59]`,
 right: `[222, 157, 168, 71, 195, 237, 77, 237, 182, 194, 17, 235, 182, 214, 204, 80]`', src/main.rs:9:5
> RUSTFLAGS='-C target-cpu=broadwell' cargo run --release
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `[103, 175, 2, 16, 66, 180, 192, 20, 55, 121, 111, 21, 82, 184, 106, 59]`,
 right: `[222, 157, 168, 71, 195, 237, 77, 237, 182, 194, 17, 235, 182, 214, 204, 80]`', src/main.rs:9:5
> RUSTFLAGS='-C target-cpu=skylake' cargo run --release
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `[103, 175, 2, 16, 66, 180, 192, 20, 55, 121, 111, 21, 82, 184, 106, 59]`,
 right: `[222, 157, 168, 71, 195, 237, 77, 237, 182, 194, 17, 235, 182, 214, 204, 80]`', src/main.rs:9:5

I bumped into this when compiling with target-cpu=native and assumed it was related to rust-lang/rust#54688, but after minimising the testcase I don't think it is. My next guess is an llvm bug but I thought I'd make an issue here in case anyone else bumps into it or wants to help investigate.

Occurs on stable:

rustc 1.37.0 (eae3437df 2019-08-13)
binary: rustc
commit-hash: eae3437dfe991621e8afdc82734f4a172d7ddf9b
commit-date: 2019-08-13
host: x86_64-apple-darwin
release: 1.37.0
LLVM version: 8.0

and nightly:

rustc 1.39.0-nightly (29a54035c 2019-08-19)
binary: rustc
commit-hash: 29a54035c77cb2ba7ea2c24b2437760d0495a2c8
commit-date: 2019-08-19
host: x86_64-apple-darwin
release: 1.39.0-nightly
LLVM version: 9.0

Tested on Broadwell (Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz) and Skylake (Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz).

[newpavlov]

Looks like the problem originates in the aes-soft crate. I can reproduce it by simply running cargo test --release with the reported target-cpu flags. IvyBridge and later have AES-NI, so they use aesni. But interestingly enough running:

RUSTFLAGS='-C target-cpu=ivybridge' cargo test --release

for aes-soft does not result in the miscompilation.

UPD: Ah, you already use aes-soft in your example.

Can you create a Rust issue and link this bug there? I will keep it open until the issue gets resolved.

[newpavlov]

@tarcieri
Should we use rustsec to notify users of this crate?

[tarcieri]

@newpavlov yes, sounds good to me

[anonymous6727]

The LLVM and Rust issues were resolved.

I've tested the code and commands from the opening post, and they all succeed for me.

• aes-soft v0.3.3
• nightly-x86_64-unknown-linux-gnu AND stable-x86_64-unknown-linux-gnu

So I think this can be closed.