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: <20240201044735.GC2356784@mit.edu>
Date: Wed, 31 Jan 2024 23:47:35 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: "Dr. Greg" <greg@...ellic.com>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "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>,
        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 02:35:32PM -0600, Dr. Greg wrote:
> I think it would demonstrate a lack of appropriate engineering
> diligence on the part of our community to declare RDRAND 'busted' at
> this point.
> 
> While it appeares to be trivially easy to force RDSEED into depletion,
> there does not seem to be a suggestion, at least in the open
> literature, that this directly or easily translates into stalling
> output from RDRAND in any type of relevant adversarial fashion.
> 
> If this were the case, given what CVE's seem to be worth on a resume,
> someone would have rented a cloud machine and come up with a POC
> against RDRAND in a multi-tenant environment and then promptly put up
> a web-site called 'Random Starve' or something equally ominous.

I suspect the reason why DOS attacks aren't happening in practice, is
because of concerns over the ability to trust the RDRAND (how do you
prove that the NSA didn't put a backdoor into the hardware with
Intel's acquisence --- after all, the NSA absolutely positively didn't
encourage the kneecaping of WEP and absolutely didn't put a trapdoor
into DUAL_EC_DRBG...)  since it can not externally audited and verfied
by a third party, in contrast to the source code for the /dev/random
driver or the RNG used in OpenSSL.

As a result, most random number generators use RDRAND in combination
with other techniques.  If RDRAND is absolutely trustworthy, the extra
sources won't hurt --- and if it isn't trustworthy mixing in other
sources will likely make things harder for Fort Meade.  And even if
these other sources might be observable for someone who can listen in
on the inter-packet arrival times on the LAN (for example), it might
not be so easy for an analyst sitting at their desk in Fort Meade.

And once you do _that_, you don't need to necessarily loop on RDRAND,
because it's one of multiple sources of entropies that are getting
mixed togethwer.  Hence, even if someone drives RDRAND into depletion,
if they are using getrandom(2), it's not a big deal.

There's a special case with Confidential Compute VM's, since the
assumption is that you want to protect against even a malicious
hypervisor who could theoretically control all other sources of timing
uncertainty.  And so, yes, in that case, the only thing we can do is
Panic if RDRAND fails.

   	    	  		     	 - Ted