Repository navigation
miri fails on chacha20 with incorrectly gated Intel intrinsic #579
Copy link
Copy link
Closed
Description
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: <×tamp::context::v7_support::ContextV7 as timestamp::ClockSequence>::generate_timestamp_sequence
at src/timestamp.rs:466:9: 466:68
14: timestamp::Timestamp::from_unix::<u64, ×tamp::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.
Metadata
Metadata
Assignees
Labels
No labels
Activity
tarcieri commentedon Aug 26, 2026
This is the likely culprit: RustCrypto/utils#1513
I will yank the latest
cpufeaturesrelease.KodrAus commentedon Aug 26, 2026
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 commentedon Aug 26, 2026
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_epi32instruction is inaccurately gated even if there's probably nothing left that supports SSE2 without also supporting SSE4.1.EDIT:
Ah, I probably just raced the yank 😄
tarcieri commentedon Aug 26, 2026
If things are building now I’ll go ahead and close this
newpavlov commentedon Aug 26, 2026
I think it's a genuine issue with our SSE2 backend. This line is UB since we use intrinsic requiring
sse4.1in 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 withunsafe(requires higher MSRV).As for
cpufeatures, I think it's fine to un-yank it.RalfJung commentedon Aug 28, 2026
That is strange. What are the old and new versions of Miri you tried?
RalfJung commentedon Aug 28, 2026
If I try this with a current Miri on the playground, I do get the expected error.
RalfJung commentedon Aug 28, 2026
I think the successful run just didn't use the newer cpufeatures?
Looks like there's no lockfile pinning these version, so re-runs can arbitrarily change which exact dependencies are used.
KodrAus commentedon Aug 29, 2026
Ah yes, sorry I think that was the case; I originally misattributed my change to the
nightlyI was targeting, not the version yank which happened around the same time.chore(deps): bump chacha20 to 0.10.2 to resolve yanked 0.10.0
chore(deps): bump chacha20 to 0.10.2 to resolve yanked 0.10.1
fix(deps): take chacha20 0.10.2, since 0.10.0 and 0.10.1 were yanked