Pretty sure we should be marking this as WontFix (as far as rand goes) :)

That documentation is bad and jschuh@ can speak more to it. The upside is that RtlGenRandom() is part of the Windows FIPS security boundary, even in Win 10, so they literally cannot remove that method. Using CryptGenRandom is explicitly not desired (will load 3P DLLs, call into 3P DLLs, and adds a heavy amount of function indirection that, per the FIPS document, will just call RtlGenRandom). The Community Additions were the part where MSDN had wiki bits, and Microsoft officially documented that the MSDN part was out of date ;) Justin and I had the discussion about this in the way beyond (... 4 or 5 years ago) about formalizing the current impl.

The remark on SecureZeroMemory is also related to some of their FIPS stuff, and is not applicable.

RtlGenRandom is pretty never-fail, so the fact that the check is failing is a real issue worth investigating. It looks like it's related to sandboxed code, so perhaps there's something up there? Is it possible these threads are being spun up before the loader has completed loading AdvApi32?

I concur with the rsleevi@ on all counts... but I'm replying mostly because I wanted to point out that the documentation recommends using CryptGenRandom(), which is also deprecated. Turtles... 😜

(I should also mention that loading CAPI or CNG will almost certainly break win32k lockdown, which is all manner of catastrophically bad.)

Sounds good. gab@, it does sound like there's a real initialization issue with your patchset though, as that function should never fail (from both windbg and the FIPS security policy, it's pretty much doing unexciting things).

So we should try to figure out why you're running into failures, as we want to make sure it's not sandboxing related and not related to module initialization.

Ok thanks for your input. Maybe it's possible this thread is spun up early enough to sometimes get ahead  of loading AdvApi32, but that'd be surprising to me as it's spun up during BrowserMainLoop::CreateThreads() which is early as far as initializing the browser is concerned but late as far as loading DLLs is concerned... No idea, but I also don't badly need rand there so I'll just drop it and move on..

Yeah, I was definitely concurring with rsleevi@ on the point about it not failing. That's a critical function (the sandbox even warms it up), so something is very, very wrong if it's breaking.

yes I agree with what's already been said here, I don't think we can change this code to call anything other than RtlGenRandom (via the SystemFunction036 trick) without risking breaking other stuff that relies on this running without massive other dependencies.

I doubt this is sandbox related, but more related to just a race and advapi32.dll - perhaps it's worth writing a small test program to fire up a load of threads and call RtlGenRandom and see if you can get this to happen without sandbox.

Here's a minimized repro : https://chromium-review.googlesource.com/c/chromium/src/+/1066458

I couldn't repro the flakes locally.

I'm genuinely curious what happens if we were to retry RtlGenRandom  on failure. 🤔

how about trying adding an explicit load of advapi32.dll early in process startup, to check if this is a load race or not?

Setting bug status so I see updates :)

Hey Will, you're welcome to give this a shot, here's a minimized repro : https://chromium-review.googlesource.com/c/chromium/src/+/1066458.

I will not be able to spend more time on this unfortunately as using rand in this code is not necessary at all and I'm already spread thin.