Skip to content

Disable AES intrinsics on aarch64 Miri #585

Closed

Description

@nazar-pc

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.

Activity

  1. newpavlov commented on Aug 28, 2026

    @newpavlov
    Member

    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.

  2. nazar-pc commented on Aug 28, 2026

    @nazar-pc
    Author

    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) 😅

  3. RalfJung commented on Aug 28, 2026

    @RalfJung

    compiling for macOS with -aes feels like I'm doing something I'm not supposed to (if it works at all) 😅

    If rustc lets you do it it should be fine. We do emit warnings when you do actually problematic stuff with target features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions