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]

Date: Tue, 30 Jan 2024 09:31:51 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Reshetova, Elena" <elena.reshetova@...el.com>,
 "Jason A. Donenfeld" <Jason@...c4.com>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: 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 1/30/24 05:45, Reshetova, Elena wrote:
>> You're the Intel employee so you can find out about this with much
>> more assurance than me, but I understand the sentence above to be _way
>> more_ true for RDRAND than for RDSEED. If your informed opinion is,
>> "RDRAND failing can only be due to totally broken hardware"
> No, this is not the case per Intel SDM. I think we can live under a simple
> assumption that both of these instructions can fail not just due to broken
> HW, but also due to enough pressure put into the whole DRBG construction
> that supplies random numbers via RDRAND/RDSEED. 

I don't think the SDM is the right thing to look at for guidance here.

Despite the SDM allowing it, we (software) need RDRAND/RDSEED failures
to be exceedingly rare by design.  If they're not, we're going to get
our trusty torches and pitchforks and go after the folks who built the
broken hardware.

Repeat after me:

	Regular RDRAND/RDSEED failures only occur on broken hardware

If it's nice hardware that's gone bad, then we WARN() and try to make
the best of it.  If it turns out that WARN() was because of a broken
hardware _design_ then we go sharpen the pitchforks.

Anybody disagree?