Disable AES intrinsics on x86-64 Miri

[nazar-pc]

Similarly to #585, for targets with aes feature enabled the following happens:

error: unsupported operation: can't call LLVM intrinsic `llvm.x86.aesni.aeskeygenassist` on architecture `x86_64`
   --> ~/.cache/rustup/toolchains/nightly-2026-08-25-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/../../stdarch/crates/core_arch/src/x86/aes.rs:100:14
    |
100 |     unsafe { aeskeygenassist(a, IMM8 as u8) }
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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::tes`
    = note: stack backtrace:
            0: core::arch::x86_64::_mm_aeskeygenassist_si128::<1>
                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/x86/aes.rs:100:14: 100:44
            1: aes::backends::x86_aes::expand::aes128_expand_key::expand_round::<1>
                at ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/aes-0.9.3/src/backends/x86_aes/expand.rs:17:14: 17:46
            2: aes::backends::x86_aes::expand::aes128_expand_key

This is not an issue for generic x86-64-v1 target where aes feature is not mandatory.

[newpavlov]

Have you enabled the target feature using RUSTFLAGS? IIRC there are no x86 targets which enable it by default.

[nazar-pc]

Yes, I did (more specifically I compile for znver4 target, which includes aes feature)

[newpavlov]

I don't think you should use target-cpu with Miri. :) Considering that, I am inclined to leave it as-is. Miri supports all other AES-NI intrinsics, so it's probably better to improve Miri in this regard (see #389).

[nazar-pc]

Well, I do want to test other things that znver4 enables. Being unable to use generic code path in aes crate in the process would mean I have to re-implement AES encoding/decoding myself 😕

[newpavlov]

Until Miri implements the intrinsic support, you can pass either -C target-feature=-aes or --cfg aes_backend="soft" in addition to target-cpu=znver4. You implicitly enabled target features which Miri does not fully support, so breakage like this can happen, so IMO it's your responsibility to work around it. You wouldn't expect for all crates to work under Miri with something like enabled AVX-512 target features, would you?

[nazar-pc]

I have the following in my ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = [
    "-C", "target-cpu=znver4",
    "-C", "linker=clang",
    "-C", "link-arg=--ld-path=wild"
]

It globally compiles everything for my CPU. I don't specify anything specifically in any of the projects I'm working on, and I would really like for cargo miri test to "just work" (which it did until recent cpufeatures update).

Neither -C target-feature=-aes nor --cfg aes_backend="soft" are a great experience. If aes_backend="soft" wasn't an annoying configuration flag I'd just add this and be done with it:

[target.'cfg(miri)'.dependencies]
aes = { workspace = true, features = ["soft"] }

This is especially important for things to "just work" when LLMs or external contributors more generally try to run the tests after changes. I can't expect them to immediately know about --cfg aes_backend="soft" when they hit an unfamiliar Miri error.

You wouldn't expect for all crates to work under Miri with something like enabled AVX-512 target features, would you?

I kind of do actually. And I have a lot of dependencies in the workspace and run thousands of tests under Miri (excluding only those that are too slow or miss features under Miri), including those that use supported platform-specific intrinsics. If any of the crates do not work, I tend to 1) open Miri issue 2) contribute to the crate to make it work under Miri. This is especially true for an extremely generic and common crate such as aes.

[newpavlov]

The best option would be to contribute to Miri to add support for aeskeygenassist (i.e. the first item in your list). One nice bonus of that will be a much faster Miri performance on AES parts of your project.

If you really want to work around it from Cargo.toml, then you could use the following hack:

[target.'cfg(miri)'.dependencies]
cpufeatures = { version = "=0.3.0" }

[nazar-pc]

If you really want to work around it from Cargo.toml, then you could use the following hack:

That is even worse:

nazar-pc@nazar-pc:/w/g/abundance> cargo clippy --all-targets
    Updating crates.io index
error: failed to select a version for `cpufeatures`.
    ... required by package `ab-proof-of-time v0.1.0 (../abundance/crates/shared/ab-proof-of-time)`
    ... which satisfies path dependency `ab-proof-of-time` (locked to 0.1.0) of package `ab-client-proof-of-time v0.0.1 (../abundance/crates/node/ab-client-proof-of-time)`
    ... which satisfies path dependency `ab-client-proof-of-time` (locked to 0.0.1) of package `ab-client-block-authoring v0.0.1 (../abundance/crates/node/ab-client-block-authoring)`
versions that meet the requirements `=0.3.0` are: 0.3.0

all possible versions conflict with previously selected packages

  previously selected package `cpufeatures v0.3.1`
    ... which satisfies dependency `cpufeatures = "^0.3.1"` of package `ab-riscv-interpreter v0.1.0 (../abundance/crates/execution/ab-riscv-interpreter)`
    ... which satisfies path dependency `ab-riscv-interpreter` (locked to 0.1.0) of package `ab-riscv-act4-runner v0.0.1 (../abundance/crates/execution/ab-riscv-act4-runner)`

failed to select a version for `cpufeatures` which could resolve this conflict

All of the suggestions so far are suboptimal and the cost of fixing it is just

- any(target_arch = "x86_64", target_arch = "x86")
+ all(not(miri), any(target_arch = "x86_64", target_arch = "x86"))

And no downstream users would have to know about it.

[newpavlov]

Why your crate needs cpufeatures v0.3.1?

And no downstream users would have to know about it.

You should know about this because you enable a target feature which is not fully supported by Miri.

I believe we do everything correctly on our side (the AArch64 case is an exception since unsupported feature gets enabled by default, but it should be eventually fixed either by rust-lang/miri#5294, or by properly adding the target feature support) and this approach is future-proof in regards to potential future Miri developments.

[nazar-pc]

Why your crate needs cpufeatures v0.3.1?

Several reasons:

• Use of deprecated syntax that forces me to litter the code with lint suppressions: Use ::MAX constant instead of deprecated ::max_value() associated method utils#1515
• I like to keep my dependencies up to date and not getting notifications about outdated dependencies from various tools
• I hate to force a fixed version of dependencies because it infects everything around it in the workspace and for all downstream users, causing conflict resolution failures just like I have specified above. It can only be a very short term last resort option.

I believe we do everything correctly on our side (the AArch64 case is an exception since unsupported feature gets enabled by default, but it should be eventually fixed either by rust-lang/miri#5294, or by properly adding the target feature support) and this approach is future-proof in regards to potential future Miri developments.

On cpufeatures side I tend to agree. But stubbornly using intrinsics that you know are not implemented on Miri is where I'm leaning the other way. And not enabling it on Miri will continue working just fine even when Miri gains support for those intrinsics.

So I'm hoping that either soft becomes a regular feature or not(miri) is added to the code base, so there is a pleasant enough way to handle this. For example blake3 has pure and portable features that can be used to avoid both C/Assembly and platform-specific Rust intrinsics.

[newpavlov]

We intentionally moved from force-soft crate feature to configuration flags for a number of reasons, so we are highly unlikely to bring them back.

Gating out Miri for a non-default target feature is IMO a bad hack (and a pretty annoying one at that since it has to be done in a number of places, not just one). If you want convenience with your pretty unconventional setup, then the only proper solution is to add support for the intrinsic to Miri.

[RalfJung]

I have the following in my ~/.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = [
"-C", "target-cpu=znver4",
"-C", "linker=clang",
"-C", "link-arg=--ld-path=wild"
]

It globally compiles everything for my CPU. I don't specify anything specifically in any of the projects I'm working on, and I would really like for cargo miri test to "just work" (which it did until recent cpufeatures update).

Maybe there's a way to make it so that this does not apply to Miri. I'm not very experienced with cargo profiles and things like that, but there could be something there?