Skip to content

miri fails on chacha20 with incorrectly gated Intel intrinsic #579

Closed

Description

@KodrAus

I just noticed this in uuid:

error: Undefined Behavior: calling a function that requires unavailable target features: sse4.1
   --> /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/chacha20-0.10.1/src/backends/sse2.rs:133:22
    |
133 |     core.state[13] = _mm_extract_epi32(backend.v[3], 1) as u32;
    |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: this is on thread `timestamp::cont`
    = note: stack backtrace:
            0: chacha20::backends::sse2::rng_inner::<chacha20::R12, chacha20::variants::Legacy>
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/chacha20-0.10.1/src/backends/sse2.rs:133:22: 133:56
            1: chacha20::rng::<impl rand::rand_core::block::Generator for chacha20::ChaChaCore<chacha20::R12, chacha20::variants::Legacy>>::generate
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/chacha20-0.10.1/src/rng.rs:76:33: 76:80
            2: <rand::rngs::thread::ReseedingCore as rand::rand_core::block::Generator>::generate
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand-0.10.2/src/rngs/thread.rs:56:9: 56:37
            3: rand::rand_core::block::BlockRng::<rand::rngs::thread::ReseedingCore>::next_u64_from_u32
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand_core-0.10.1/src/block.rs:258:13: 258:50
            4: <rand::prelude::ThreadRng as rand::TryRng>::try_next_u64
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand-0.10.2/src/rngs/thread.rs:228:12: 228:35
            5: <rand::prelude::ThreadRng as rand::Rng>::next_u64
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand_core-0.10.1/src/lib.rs:78:15: 78:34
            6: rand::distr::integer::<impl rand::distr::Distribution<u64> for rand::distr::StandardUniform>::sample::<rand::prelude::ThreadRng>
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand-0.10.2/src/distr/integer.rs:52:9: 52:23
            7: <rand::prelude::ThreadRng as rand::RngExt>::random::<u64>
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand-0.10.2/src/rng.rs:97:9: 97:37
            8: rand::random::<u64>
                at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rand-0.10.2/src/lib.rs:194:5: 194:19
            9: <rng::imp::RngImp as rng::Rng>::u64
                at src/rng.rs:40:13: 40:27
            10: rng::u64
                at src/rng.rs:14:5: 14:23
            11: timestamp::context::v7_support::Counter::reseed
                at src/timestamp.rs:933:44: 933:61
            12: <timestamp::context::v7_support::ContextV7 as timestamp::ClockSequence>::generate_timestamp_sequence
                at src/timestamp.rs:836:31: 836:75
            13: <&timestamp::context::v7_support::ContextV7 as timestamp::ClockSequence>::generate_timestamp_sequence
                at src/timestamp.rs:466:9: 466:68
            14: timestamp::Timestamp::from_unix::<u64, &timestamp::context::v7_support::ContextV7>
                at src/timestamp.rs:112:13: 112:71
            15: timestamp::context::v7_support::tests::context
                at src/timestamp.rs:1076:27: 1076:80
            16: timestamp::context::v7_support::tests::context::{closure#0}
                at src/timestamp.rs:1070:25: 1070:25

I'm guessing miri may have just started asserting on this sort of thing? I had a quick look through the source here and it looks like we do only gate on SSE2, while Intel intrinsics suggest that instruction is SSE4.1.

Activity

  1. tarcieri commented on Aug 26, 2026

    @tarcieri
    Member

    This is the likely culprit: RustCrypto/utils#1513

    I will yank the latest cpufeatures release.

  2. KodrAus commented on Aug 26, 2026

    @KodrAus
    Author

    I did notice I had an outdated miri running in CI, and it does build now I've updated it: https://github.com/uuid-rs/uuid/actions/runs/33014513986/job/98329124924

  3. KodrAus commented on Aug 26, 2026

    @KodrAus
    Author

    I'm not entirely sure yet why it succeeds with a recent miri, but not an older one. It does seem like this _mm_extract_epi32 instruction is inaccurately gated even if there's probably nothing left that supports SSE2 without also supporting SSE4.1.

    EDIT:

    I went ahead and yanked cpufeatures v0.3.1 which included this PR.

    Ah, I probably just raced the yank 😄

  4. tarcieri commented on Aug 26, 2026

    @tarcieri
    Member

    If things are building now I’ll go ahead and close this

  5. newpavlov commented on Aug 26, 2026

    @newpavlov
    Member

    I think it's a genuine issue with our SSE2 backend. This line is UB since we use intrinsic requiring sse4.1 in a function with only #[target_feature(enable = "sse2")] without any additional checks and Miri rigtfully complains about it (dunno why it happens only on older releases). It would've been caught if the function was not marked with unsafe (requires higher MSRV).

    As for cpufeatures, I think it's fine to un-yank it.

  6. RalfJung commented on Aug 28, 2026

    @RalfJung

    I did notice I had an outdated miri running in CI, and it does build now I've updated it

    That is strange. What are the old and new versions of Miri you tried?

  7. RalfJung commented on Aug 28, 2026

    @RalfJung

    If I try this with a current Miri on the playground, I do get the expected error.

  8. RalfJung commented on Aug 28, 2026

    @RalfJung

    I think the successful run just didn't use the newer cpufeatures?

    Downloaded cpufeatures v0.3.0

    Looks like there's no lockfile pinning these version, so re-runs can arbitrarily change which exact dependencies are used.

  9. KodrAus commented on Aug 29, 2026

    @KodrAus
    Author

    Ah yes, sorry I think that was the case; I originally misattributed my change to the nightly I was targeting, not the version yank which happened around the same time.

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