You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RustCrypto/utils#1513 had good intentions, but Miri doesn't implement many intrinsics yet. So unless you want to update cpufeatures to capture that, aes crate should not use intrinsics on aarch64 Miri, otherwise it is currently unusable there:
error: unsupported operation: can't call LLVM intrinsic `llvm.aarch64.crypto.aese` on architecture `aarch64`
--> ~/.cache/rustup/toolchains/nightly-2026-08-25-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:3247:14
|
3247 | unsafe { _vaeseq_u8(data, key) }
| ^^^^^^^^^^^^^^^^^^^^^ unsupported operation occurred here
|
= help: this means the program tried to do something Miri does not support; it does not indicate a bug in the program
= note: this is on thread `aes::tests::test_create_verify`
= note: stack backtrace:
0: core::arch::aarch64::vaeseq_u8
at ~/.cache/rustup/toolchains/nightly-2026-08-25-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:3247:14: 3247:35
1: aes::backends::aarch64_aes::expand::sub_word
at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aes-0.9.2/src/backends/aarch64_aes/expand.rs:82:21: 82:52
This specifically fails on macOS where AES capability is the default enabled feature. For Linux to hit the same +aes needs to be used, but when you do the result will be exactly the same.
P.S. Using annoying configuration flags instead of normal features for things like aes_backend means I can't work around this cleanly downstream either.
This is unfortunate... I will try to add exception for this combination later today.
Using annoying configuration flags instead of normal features for things like aes_backend means I can't work around this cleanly downstream either.
As a workaround you also can use the --target flag to select an alternative target where target features unsupported by Miri are not enabled by default.
x86-64 has the widest coverage of intrinsics from my experience, but aarch64 is less lucky. To your question in RustCrypto/utils#1513 Miri definitely doesn't implement the full set of intrinsics and doesn't even try to, it is best effort based on how common the actual use is (see rust-lang/miri#5204 for example).
So Miri with refuse to execute intrinsics even if it implements them unless the feature is enabled at compile time, but the inverse is not true: enabling feature doesn't imply all intrinsics are available.
As a workaround you also can use the --target flag to select an alternative target where target features unsupported by Miri are not enabled by default.
Sure, but compiling for macOS with -aes feels like I'm doing something I'm not supposed to (if it works at all) 😅
Activity
newpavlov commentedon Aug 28, 2026
This is unfortunate... I will try to add exception for this combination later today.
As a workaround you also can use the
--targetflag to select an alternative target where target features unsupported by Miri are not enabled by default.nazar-pc commentedon Aug 28, 2026
x86-64 has the widest coverage of intrinsics from my experience, but aarch64 is less lucky. To your question in RustCrypto/utils#1513 Miri definitely doesn't implement the full set of intrinsics and doesn't even try to, it is best effort based on how common the actual use is (see rust-lang/miri#5204 for example).
So Miri with refuse to execute intrinsics even if it implements them unless the feature is enabled at compile time, but the inverse is not true: enabling feature doesn't imply all intrinsics are available.
Sure, but compiling for macOS with
-aesfeels like I'm doing something I'm not supposed to (if it works at all) 😅RalfJung commentedon Aug 28, 2026
If rustc lets you do it it should be fine. We do emit warnings when you do actually problematic stuff with target features.