miri fails on chacha20 with incorrectly gated Intel intrinsic

[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.

[tarcieri]

This is the likely culprit: RustCrypto/utils#1513

I will yank the latest cpufeatures release.

[KodrAus]

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

[KodrAus]

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 😄

[tarcieri]

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

[newpavlov]

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.