RE: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails

[Reshetova, Elena]

> On Wed, Jan 31, 2024 at 9:17 AM Reshetova, Elena
> <elena.reshetova@xxxxxxxxx> 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