AES test (and AES-GCM) fails on ARMv7 (RPi3)

[PAStheLoD]

Running cargo test on a Raspberry Pi 3, with Linux 4.9 and Rust 1.23.0 the following assertion error occurs:

---- aead::aes_gcm::tests::test_aes stdout ----
        thread 'aead::aes_gcm::tests::test_aes' panicked at 'assertion failed: `(left == right)`
  left: `[121, 11, 109, 252, 108, 61, 63, 255, 205, 252, 211, 95, 187, 220, 229, 15]`,
 right: `[105, 196, 224, 216, 106, 123, 4, 48, 216, 205, 183, 128, 112, 180, 197, 90]`', src/aead/aes_gcm.rs:151:12
note: Run with `RUST_BACKTRACE=1` for a backtrace.
src/aead/aes_tests.txt: Test panicked.
Key = 000102030405060708090a0b0c0d0e0f
Input = 00112233445566778899aabbccddeeff
Output = 69c4e0d86a7b0430d8cdb78070b4c55a
thread 'aead::aes_gcm::tests::test_aes' panicked at 'assertion failed: `(left == right)`
  left: `[138, 63, 183, 175, 198, 219, 55, 142, 49, 98, 111, 77, 129, 129, 172, 158]`,
 right: `[142, 162, 183, 202, 81, 103, 69, 191, 234, 252, 73, 144, 75, 73, 96, 137]`', src/aead/aes_gcm.rs:151:12
src/aead/aes_tests.txt: Test panicked.
Key = 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
Input = 00112233445566778899aabbccddeeff
Output = 8ea2b7ca516745bfeafc49904b496089
thread 'aead::aes_gcm::tests::test_aes' panicked at 'Test failed.', src/test.rs:348:8


failures:
    aead::aes_gcm::tests::test_aes

Just for the record, this bug originally surfaced here.

[PAStheLoD]

Another data point: using the non-v7 ARM target (arm-unknown-linux-gnueabihf) leads to all tests passing.

[briansmith]

Thanks for reporting this.

From @PAStheLoD's comment in the Rustls issue:

Also regarding the rustls test SIGBUS, dmesg has something informative (after echo 3 > /proc/cpu/alignment ... meh):

Jan 26 12:19:21 xxx kernel: Alignment trap: negotiated_ciph (2339) PC=0x006d9df8 Instr=0xecd6cb04 Address=0x006d9721 FSR 0x001
Jan 26 12:19:21 xxx kernel: Alignment trap: not handling instruction ecd6cb04 at [<006d9df8>]
Jan 26 12:19:21 xxx kernel: Unhandled fault: alignment exception (0x001) at 0x006d9721
Jan 26 12:19:21 xxx kernel: pgd = 9e2d8000
Jan 26 12:19:22 xxx kernel: [006d9721] *pgd=1e3ce835, *pte=0da5a59f, *ppte=0da5ae7e
Jan 26 12:19:23 xxx kernel: Alignment trap: negotiated_ciph (2339) PC=0x006d9f0a Instr=0xecd80b04 Address=0x006d9731 FSR 0x001
Jan 26 12:19:23 xxx kernel: Alignment trap: not handling instruction ecd80b04 at [<006d9f0a>]
Jan 26 12:19:23 xxx kernel: Unhandled fault: alignment exception (0x001) at 0x006d9731
Jan 26 12:19:23 xxx kernel: pgd = 9e2d8000
Jan 26 12:19:23 xxx kernel: [006d9731] *pgd=1e3ce835, *pte=0da5a59f, *ppte=0da5ae7e
/proc/cpu/alignment:

User: 4
System: 1226 (__csum_ipv6_magic+0x1c/0xc8)
Skipped: 4
Half: 0
Word: 0
DWord: 0
Multi: 1226
User faults: 3 (fixup+warn)
So it should fixup the unaligned access, but it probably can't. And there were no other alignment issues during cargo test.

It would be awesome to get a stacktrace with line numbers of where the misaligned access happens.

[briansmith]

See #629 about finding some way to ensure that alignment stuff is consistent between the C compiler and Rust compiler and the assembly code.

I am not sure that this is an alignment-related issue yet, but that seems like a promising avenue to pursue because you mentioned the results are different for the ARMv6 target than for the ARMv7 target, and rustc just recently attemped to resolve some alignment-related issues on ARMv6 in rust-lang/rust#45094.

That said, there's numerous differences between ARMv6 and ARMv7 in the code.

[briansmith]

#702 found a type mismatch in the FFI declaration for GFp_AES_set_encrypt_key that affects only the test test_aes. So it could be that this bug is in the test, which that PR would fix.

[briansmith]

Based on rwf2/Rocket#650, this isn't a test-only issue.

[briansmith]

commit 225f6b0, first released in ring 0.14.2, probably fixes the AES-GCM case. Perhaps the GFp_AES_set_encrypt_key fix mentioned above, in combination with commit 225f6b0, fixes this issue?

@PAStheLoD Could you please test ring 0.14.2 on your Raspberry Pi 3 and report back? Thanks!

[briansmith]

Closing this since I think it was fixed based on the previous comment. Please re-open if you still have a problem.