std::sys::windows::rand::hashmap_random_keys() panics on some systems

[marti4d]

Hi there,

In Issue #94098, Firefox was running into a problem where any use of std::collections::HashMap was causing a crash on the machines of some small subset of users.

The root cause is that Bcrypt.dll or bcryptprimitives.dll will fail to load on some machines, causing any attempt to generate random numbers to also fail, leading Rust std to panic. Note that this was a regression from previous std behavior, and was caused when std made the choice to move away from RtlGenRandom to BCrypt as its only source of randomness on Win32 in #84096.

Note that this issue is likely not specific to Firefox -- It's likely any program written in Rust will have this exact same behavior on this small set of machines.

At this time, I had made PR #96917 to re-introduce RtlGenRandom as a "fallback" in case BCrypt failed to load.

Since then, I see that PR #102044 attempted to re-remove RtlGenRandom and changed the fallback to use BCrypt as well. Starting with the release of this change, we are seeing crashes again in Firefox due to failing RNG on these machines. See this Bug on Bugzilla.

It appears that if BCrypt's primary provider is broken, the fallback will likely be broken as well.

My suggestion is that we should once-again re-introduce RtlGenRandom() as a fallback mechanism.

Thanks,
Chris

[marti4d]

@ChrisDenton FYI

[ChrisDenton]

Oh, I'll put a revert asap.

[marti4d]

@ChrisDenton Thanks! I wouldn't do a full revert -- I think a lot of your change is good and should stay (like using the system-preferred RNG seems like a good idea!) -- I would just perhaps get rid of the current fallback and change it back to RtlGenRandom -- It's almost-certain that if the system-preferred RNG fails, BCRYPT_RNG_ALGORITHM will fail as well.

[marti4d]

Ah, I see the revert still keeps the "preferred RNG" logic. Good stuff! Thanks :)