Messages in this thread | ![/](/images/icornerl.gif) | | From | "Jason A. Donenfeld" <> | Date | Wed, 31 Jan 2024 14:06:13 +0100 | Subject | Re: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails |
| |
On Wed, Jan 31, 2024 at 9:17 AM Reshetova, Elena <elena.reshetova@intel.com> wrote: > This matches both my understanding (I do have cryptography background > and understanding how cryptographic RNGs work) > and official public docs that Intel published on this matter. > Given that the physical entropy source is limited anyhow, and by giving > enough pressure on the whole construction you should be able to > make RDRAND fail because if the intermediate AES-CBC MAC extractor/ > conditioner is not getting its min entropy input rate, it wont > produce a proper seed for AES CTR DRBG. > Of course exact details/numbers can wary between different generations of > Intel DRNG implementation, and the platforms where it is running on, > so be careful to sticking to concrete numbers.
Alright, so RDRAND is not reliable. The question for us now is: do we want RDRAND unreliability to translate to another form of unreliability elsewhere, e.g. DoS/infiniteloop/latency/WARN_ON()? Or would it be better to declare the hardware simply broken and ask Intel to fix it? (I don't know the answer to that question.)
> That said, I have taken an AR to follow up internally on what can be done > to improve our situation with RDRAND/RDSEED.
Specifying this is an interesting question. What exactly might our requirements be for a "non-broken" RDRAND? It seems like we have two basic ones:
- One VMX (or host) context can't DoS another one. - Ring 3 can't DoS ring 0.
I don't know whether that'd be implemented with context-tied rate limiting or more state or what. But I think, short of just making RDRAND never fail, that's basically what's needed.
Jason
| ![\](/images/icornerr.gif) |