On July 5, 2022 12:57:04 PM PDT, Borislav Petkov <bp@xxxxxxxxx> wrote: >On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: >> Oh, huh. Maybe in that case I should adjust the message to say "consider >> using `random.trust_cpu=0`," which is the thing that would actually make >> a security difference. > >Why isn't that option documented in >Documentation/admin-guide/kernel-parameters.txt? > >> But actually, one thing that wasn't clear to me was: does `nordrand` >> affect what userspace sees? While random.c is okay in lots of >> circumstances, I could imagine `nordrand` playing a role in preventing >> userspace from using it, which might be desirable. Is this the case? If >> so, I can remove the nordrand chunk from this patch for v2. If not, I'll >> adjust the text to mention `random.trust_cpu=0`. > >Unfortunately, it doesn't disable the instruction. It would be lovely if >we had a switch like that... > >That's why this message is supposed to be noisy so that people can pay >attention at least. > >> In the sense that random.c can handle mostly any input without making >> the quality worse. So, you can't accidentally taint it. The only risk is >> if it thinks RDRAND is good and trustable when it isn't, but that's what >> `random.trust_cpu=0` is for. > >And that's why I'm saying that if you detect RDRAND returning the >same thing over and over again, you should simply stop using it. >Automatically. Not rely on the user to do anything. > It's just math. The only variable is your confidence level, i.e. at what level do you decide that the likelihood of pure chance is way smaller than the likelihood of hardware failure. For example, the likelihood of m n-bit samples in a row being identical is 2^-(n*(m-3/2)), and the likelihood of the CPU being destroyed by a meterorite in the same microsecond is about 2^-100.
