Messages in this thread | | | From | "Reshetova, Elena" <> | Subject | RE: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails | Date | Wed, 31 Jan 2024 18:02:53 +0000 |
| |
> 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.
Correction here: "... not reliable *in theory*". Because in practice it all depends on amount of pressure you are able to put on the overall construction, which goes into concrete numbers I warned about. That would depend on the number of available cores, and some other platform specific factors. I will work on getting this clarified externally so that there is no confusion.
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.
I agree.
Best Regards, Elena.
> > Jason
| |