Received-SPF: pass (google.com: domain of linux-kernel+bounces-44740-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <DM8PR11MB57507611D651E6D7CBC2A2F3E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Tue, 30 Jan 2024 15:21:34 +0100
Message-ID: <CAHmME9odqcxdak3HK-XD6-H0SjYmecnTsxzDhYy+-0shhTFygQ@mail.gmail.com>
Subject: Re: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 30, 2024 at 2:45=E2=80=AFPM Reshetova, Elena
<elena.reshetova@intel.com> wrote:
> No, this is not the case per Intel SDM. I think we can live under a simpl=
e
> assumption that both of these instructions can fail not just due to broke=
n
> 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=E2=80=99t
> 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.

> >
> > 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=E2=80=99t think we are only concerned with initial early boot and i=
nitial seeding.
> What about periodic reseeding of ChaCha CSPRNG? If you don=E2=80=99t get
> RDRAND/RDSEED output during this step, don=E2=80=99t we formally loose th=
e forward
> prediction resistance property of Linux RNG assuming this is the only sou=
rce
> 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.

Jason