Message-ID: <DM8PR11MB57507611D651E6D7CBC2A2F3E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Tue, 30 Jan 2024 13:45:06 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "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

> Hi Kirill,
> 
> Picking up from my last email on patch 1/2:
> 
> On Tue, Jan 30, 2024 at 9:30 AM Kirill A. Shutemov
> <kirill.shutemov@...ux.intel.com> wrote:
> > RDRAND and RDSEED instructions rarely fail. Ten retries should be
> > sufficient to account for occasional failures.
> >
> > If the instruction fails more than ten times, it is likely that the
> > hardware is broken or someone is attempting to exceed the rate at which
> > the random number generator hardware can provide random numbers.
> 
> 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. 

 then a
> WARN_ON seems like an appropriate solution, consistent with what other
> drivers do for totally broken hardware. I'm less convinced that this
> is the case also for RDSEED, but you know better than me.

I do agree that due to internal structure of DRBG it is easier to create
a situation when RDSEED will fail. But for the purpose of Linux RNG and 
confidential computing it actually doesn’t make a difference if we get an
output from RDRAND or RDSEED, as soon as we get either of them. 
Problems only start imo when both of them are made to fail. 

> 
> However, there's one potentially concerning aspect to consider: if the
> statement is "RDRAND only fails when the hardware fails", that's fine,
> but if the statement is "RDRAND only fails when the hardware fails or
> a user hammers on RDRAND in a busy loop," then this seems like a
> potential DoS vector from userspace, since RDRAND is not a privileged
> instruction. Unless there's different pools and rate limiting and
> hardware and such depending on which ring the instruction is called
> from? But I've never read about that. What's your feeling on this
> concern?

RDRAND can fail with enough load as I already said above. 
I am also not aware about any ring separation or anything like this for
RDRAND/RDSEED instructions. 

I guess your concern about DoS here is for the case when we don’t
trust the host/VMM *and* assume malicious userspace, correct? 
Because in non-confidential computing case, the Linux RNG in such
case will just use non-RDRAND fallbacks, no DoS will happen and we
should have enough entropy that is outside of userspace control.

I guess this is indeed difficult situation because we don’t have any other
entropy sources anymore (unless assume some special HW). 
But you bring a very valid point that in this case we make it easier for userspace
to make a DoS to the kernel if we require RDRAND/RDSEED to 
succeed, which is not acceptable (with exception of early boot when
we don’t have the userspace problem). 

> 
> And if the DoS thing _is_ a concern, and the use case for this WARN_ON
> in the first place is the trusted computing scenario, so we basically
> only care about early boot, then one addendum would be to only warn if
> we're in early boot, which would work because seeding via RDRAND is
> attempted pretty early on in init.c.

I don’t think we are only concerned with initial early boot and initial seeding. 
What about periodic reseeding of ChaCha CSPRNG? If you don’t get
RDRAND/RDSEED output during this step, don’t we formally loose the forward
prediction resistance property of Linux RNG assuming this is the only source
of entropy that is outside of attacker control? 

Best Regards,
Elena. 

> 
> Jason

Powered by blists - more mailing lists