Received-SPF: pass (google.com: domain of linux-kernel+bounces-44789-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 30 Jan 2024 16:00:42 +0100
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	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>
Subject: Re: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails
Message-ID: <ZbkPGl7sdg5NZMtn@zx2c4.com>
References: <20240130083007.1876787-1-kirill.shutemov@linux.intel.com>
 <20240130083007.1876787-2-kirill.shutemov@linux.intel.com>
 <CAHmME9qsfOdOEHHw_MOBmt6YAtncbbqP9LPK2dRjuOp1CrHzRA@mail.gmail.com>
 <DM8PR11MB57507611D651E6D7CBC2A2F3E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
 <CAHmME9odqcxdak3HK-XD6-H0SjYmecnTsxzDhYy+-0shhTFygQ@mail.gmail.com>
 <DM8PR11MB57507D16E4A4679AD4B4B964E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DM8PR11MB57507D16E4A4679AD4B4B964E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>

On Tue, Jan 30, 2024 at 02:55:08PM +0000, Reshetova, Elena wrote:
> 
> 
> > On Tue, Jan 30, 2024 at 2:45 PM Reshetova, Elena
> > <elena.reshetova@intel.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.

That's the first thing I mentioned -- "If you never add new material,
and you have the initial seed, then it's deterministic." The property
you mention is a good one to have and Linux usually has it. 


> 
> Best Regards,
> Elena.
> 
> > 
> > Jason