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]

Date: Tue, 30 Jan 2024 14:55:08 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
CC: "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>, 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



> On Tue, Jan 30, 2024 at 2:45 PM Reshetova, Elena
> <elena.reshetova@...el.com> wrote:
> > 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.
> 
> Yea, thought so.
> 
> > 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.
> 
> Don't think about the RNG for just one second. The basic principle is
> simpler: if you have a
> `WARN_ON(unprivd_userspace_triggerable_condition)`, that's usually
> considered a DoS - panic_on_warn and such.

Ok, agree, you do bring a valid point that we should not create new 
DoS attack vectors from  userspace in such cases. 

> 
> > >
> > > 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?
> 
> If you never add new material, and you have the initial seed, then
> it's deterministic. But you still mostly can't backtrack if the state
> leaks at some future point in time.

I am not talking about backtrack resistance, i.e. when attacker learns about 
RNG state and then can recover the past output. I was talking about an attacker
learning the RNG state at some point of time (RNG compromise) and
then for RNG being able to recover over time from this state to a secure state using 
fresh entropy input that is outside of attacker control/observance.
Does Linux RNG aim to provide this property? Do people care about this? 
If noone cares about this one and Linux RNG doesn’t aim to provide it anyhow,
then I agree that we should just ensure that early entropy collection includes
RDRAND/RDSEED input for confidential VMs one way or another.

Best Regards,
Elena.

> 
> Jason