Re: [PATCH 1/2] x86/random: Retry on RDSEED failure

From: James Bottomley
Date: Fri Feb 02 2024 - 16:28:43 EST


On Fri, 2024-02-02 at 11:05 -0500, Theodore Ts'o wrote:
> On Fri, Feb 02, 2024 at 04:47:11PM +0100, James Bottomley wrote:
> >
> > It's a lot to quote, so I cut it, but all of your solutions assume
> > a rdseed/rdrand failure equates to a system one but it really
> > doesn't: in most systems there are other entropy sources.  In
> > confidential computing it is an issue because we have no other
> > trusted sources. The problem with picking on rdseed/rdrand is that
> > there are bound to be older CP s somewhere that have rng generation
> > bugs that this will
> > expose.
>
> I'm not sure what you're concerned about.  As far as I know, all of
> the CPU's have some variant of Confidential Compute have some kind of
> RDRAND-like command.  And while we're using the term RDRAND, I'd
> extend this to any CPU architecture-level RNG instruction which can
> return failure if it is subject to exhaustion attacks.

My big concern is older cpus where rdrand/rdseed don't produce useful
entropy. Exhaustion attacks are going to be largely against VMs not
physical systems, so I worry about physical systems with older CPUs
that might have rdrand issues which then trip our Confidential
Computing checks.


> > How about making the failure contingent on the entropy pool
> > not having any entropy when the first random number is requested?
>
> We have tried to avoid characterizing entropy sources as "valid" or
> "invalid".  First of all, it's rarely quite so black-and-white.
> Something which is vulnerable to someone who can spy on inter-packet
> arrival times by having a hardware tap between the CPU and the
> network switch, or a wireless radio right next to the device being
> attacked, might not be easily carried out by someone who doesn't have
> local physical access.
>
> So we may be measuring various things that might or might not have
> "entropy".  In the case of Confidential Compute, we have declared
> that none of those other sources constitute "entropy".  But that's
> not a decision that can be made by the computer, or at least until
> we've tracked the AGI problem.  (At which point, we might have other
> problems --- "I'm sorry, I'm afraid I can't do that.")

The signal for rdseed failing is fairly clear, so if the node has other
entropy sources, it should continue otherwise it should signal failure.
Figuring out how a confidential computing environment signals that
failure is TBD.

James