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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM8PR11MB57503F8ACA76B744E1A61DDCE77C2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Wed, 31 Jan 2024 18:02:53 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
CC: Daniel P. Berrangé <berrange@...hat.com>, "Hansen,
 Dave" <dave.hansen@...el.com>, "Kirill A. Shutemov"
	<kirill.shutemov@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo
 Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>, Theodore Ts'o <tytso@....edu>, "Kuppuswamy
 Sathyanarayanan" <sathyanarayanan.kuppuswamy@...ux.intel.com>, "Nakajima,
 Jun" <jun.nakajima@...el.com>, Tom Lendacky <thomas.lendacky@....com>,
	"Kalra, Ashish" <ashish.kalra@....com>, Sean Christopherson
	<seanjc@...gle.com>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
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@...el.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