Received-SPF: pass (google.com: domain of linux-kernel+bounces-59903-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <DM8PR11MB57507611D651E6D7CBC2A2F3E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
 <88a72370-e300-4bbc-8077-acd1cc831fe7@intel.com> <CAHmME9oSQbd3V8+qR0e9oPb7ppO=E7GrCW-a2RN8QNdY_ARbSQ@mail.gmail.com>
 <Zbk6h0ogqeInLa_1@redhat.com> <DM8PR11MB575052B985CA97B29A443F9AE77C2@DM8PR11MB5750.namprd11.prod.outlook.com>
 <20240206011247.GA29224@wind.enjellic.com> <ZcHoKUElwXGPzrWb@redhat.com>
 <20240206120445.GA1247@wind.enjellic.com> <20240206153529.GHZcJRwTdDkWXuopOQ@fat_crate.local>
 <20240208114444.GA23164@wind.enjellic.com> <20240209173102.GBZcZhVuFJZ8JOKTjG@fat_crate.local>
In-Reply-To: <20240209173102.GBZcZhVuFJZ8JOKTjG@fat_crate.local>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Fri, 9 Feb 2024 20:49:40 +0100
Message-ID: <CAHmME9pEVNM6UVW+pKbTZEhsnrGvq5ERMOSC1ezdrCn96q36kA@mail.gmail.com>
Subject: Re: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails
To: Borislav Petkov <bp@alien8.de>
Cc: "Dr. Greg" <greg@enjellic.com>, "Daniel P. Berrang??" <berrange@redhat.com>, 
	"Reshetova, Elena" <elena.reshetova@intel.com>, "Hansen, Dave" <dave.hansen@intel.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Thomas Gleixner <tglx@linutronix.de>, 
	Ingo Molnar <mingo@redhat.com>, Dave Hansen <dave.hansen@linux.intel.com>, 
	"H. Peter Anvin" <hpa@zytor.com>, "x86@kernel.org" <x86@kernel.org>, "Theodore Ts'o" <tytso@mit.edu>, 
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, 
	"Nakajima, Jun" <jun.nakajima@intel.com>, Tom Lendacky <thomas.lendacky@amd.com>, 
	"Kalra, Ashish" <ashish.kalra@amd.com>, Sean Christopherson <seanjc@google.com>, 
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Boris,

While you're here, I was wondering if you could comment on one thing relate=
d:

On Fri, Feb 9, 2024 at 6:31=E2=80=AFPM Borislav Petkov <bp@alien8.de> wrote=
:
> Now, considering that this is a finite resource, you can imagine that
> there can be scenarios where that source can be depleted.

Yea, this makes sense.

[As an aside, I would like to note that a different construction of
RDRAND could keep outputting good random numbers for a reeeeeallly
long time without needing to reseed, or without penalty if RDSEED is
depleted, and so could be made to actually never fail. But given the
design goals of RDRAND, this kind of crypto is highly likely to never
be implemented, so I'm not even moving to suggest that AMD/Intel just
'fix' the crypto design goals of the instruction. It's not gonna
happen for lots of reasons.]

So assuming that RDSEED and hence RDRAND can never be made to never
fail, the options are:

1. Finite resource that refills faster than whatever instruction
issuance latency, so it's never observably empty. (Seems unlikely)
2. More secure sharing of the finite resource.

It's this second option I wanted to ask you about. I wrote down what I
thought "secure sharing" meant here [1]:

> - One VMX (or host) context can't DoS another one.
> - Ring 3 can't DoS ring 0.

It's a bit of a scheduling/queueing thing, where different security
contexts shouldn't be able to starve others out of the finite resource
indefinitely.

What I'm wondering is if that kind of fairness is even possible to
achieve in the hardware or the microcode. I don't really know how that
all works under the covers and what sorts of "policies" and such are
feasible to implement. In suggesting it, I feel like a bit of a
presumptuous kernel developer talking to hardware people, not fully
appreciating their domain and its challenges. For, if this were just a
C program, I know exactly what I'd do, but we're talking about a CPU
here.

Is it actually possible to make RDRAND usage "fair" between different
security contexts? Or am I totally delusional and this is not how the
hardware works or can ever work?

Jason

[1] https://lore.kernel.org/all/CAHmME9ps6W5snQrYeNVMFgfhMKFKciky=3D-UxxGFb=
Ax_RrxSHoA@mail.gmail.com/