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

[Dr. Greg]

On Wed, Jan 31, 2024 at 11:47:35PM -0500, Theodore Ts'o wrote:
> 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.

All well taken points, the Linux RNG and associated community has
benefited from your and Jason's concerns and work on all of this.

However, whether or not DOS attacks based on RNG depletion are
happening in the wild, and the reasons they are not, are orthogonal to
whether or not they can be proven to exist, which was the point I was
trying to make.

Demonstrating a vulnerability in something as critical as Intel's RNG
implementation would be a big motivation for some research group.  The
fact that hasn't occurred would seem to suggest that the RDRAND
resource depletion we are concerned with is not adversarially
exploitable.

I suspect that the achievable socket core count cannot effectively
overwhelm the 1022x amplification factor inherent in the design of the
RDSEED based seeding of RDRAND.

We will see if Elena can come up with what Intel engineering's
definition of 'astronomical' is.. :-)

> 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.

Indeed.

The bigger question, which I will respond to Elena with, is how much
this issue calls the entire question of confidential computing into
question.

>    	    	  		     	 - Ted

Have a good day, it has been a long time since you and I were standing
around with Phil Hughes in the Galleria in Atlanta argueing about
whether or not Active Directory was going to dominate enterprise
computing.

It does seem to have gained some significant amount of traction... :-)

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project