Received-SPF: pass (google.com: domain of linux-kernel+bounces-40264-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 26 Jan 2024 07:23:55 -0800
In-Reply-To: <20240126134230.1166943-1-kirill.shutemov@linux.intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240126134230.1166943-1-kirill.shutemov@linux.intel.com>
Message-ID: <ZbPOi0760srv0rE0@google.com>
Subject: Re: [RFC] Randomness on confidential computing platforms
From: Sean Christopherson <seanjc@google.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: 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, 
	"Theodore Ts'o" <tytso@mit.edu>, "Jason A. Donenfeld" <Jason@zx2c4.com>, 
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, 
	Elena Reshetova <elena.reshetova@intel.com>, Jun Nakajima <jun.nakajima@intel.com>, 
	Tom Lendacky <thomas.lendacky@amd.com>, Ashish Kalra <ashish.kalra@amd.com>, 
	linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 26, 2024, Kirill A. Shutemov wrote:
> Problem Statement
>=20
> Currently Linux RNG uses the random inputs obtained from x86
> RDRAND/RDSEED instructions (if present) during early initialization
> stage (by mixing the obtained input into the random pool via
> _mix_pool_bytes()), as well as for seeding/reseeding ChaCha-based CRNG.
> When the calls to both RDRAND/RDSEED fail (including RDRAND internal
> retries), the timing-based fallbacks are used in the latter case, and
> during the early boot case this source of entropy input is simply
> skipped. Overall Linux RNG has many other sources of entropy that it
> uses (also depending on what HW is used), but the dominating one is
> interrupts.
>=20
> In a Confidential Computing Guest threat model, given the absence of any
> special trusted HW for the secure entropy input, RDRAND/RDSEED
> instructions is the only entropy source that is unobservable outside of
> Confidential Computing Guest TCB. However, with enough pressure on these
> instructions from multiple cores (see Intel SDM, Volume 1, Section
> 7.3.17, =E2=80=9CRandom Number Generator Instructions=E2=80=9D), they can=
 be made to
> fail on purpose and force the Confidential Computing Guest Linux RNG to
> use only Host/VMM controlled entropy sources.
>=20
> Solution options
>=20
> There are several possible solutions to this problem and the intention
> of this RFC is to initiate a joined discussion. Here are some options
> that has been considered:
>=20
> 1. Do nothing and accept the risk.
> 2. Force endless looping on RDRAND/RDSEED instructions when run in a
>    Confidential Computing Guest (this patch). This option turns the
>    attack against the quality of cryptographic randomness provided by
>    Confidential Computing Guest=E2=80=99s Linux RNG into a DoS attack aga=
inst
>    the Confidential Computing Guest itself (DoS attack is out of scope
>    for the Confidential Computing threat model).
> 3. Panic after enough re-tries of RDRAND/RDSEED instructions fail.
>    Another DoS variant against the Guest.
> 4. Exit to the host/VMM with an error indication after a Confidential
>    Computing Guest failed to obtain random input from RDRAND/RDSEED
>    instructions after reasonable number of retries. This option allows
>    host/VMM to take some correction action for cases when the load on
>    RDRAND/RDSEED instructions has been put by another actor, i.e. the
>    other guest VM. The exit to host/VMM in such cases can be made
>    transparent for the Confidential Computing Guest in the TDX case with
>    the assistance of the TDX module component.

Hell no.  Develop better hardware if you want to guarantee forward progress=
.
Don't push more complexity into the host stack for something that in all li=
kelihood
will never happen outside of buggy software or hardware.

> 5. Anything other better option?

Give the admin the option to choose between "I don't care, carry-on with le=
ss
randomness" and "I'm paranoid, panic, panic, panic!".  In other words, let =
the
admin choose between #1 and #3 at boot time.  You could probably even let t=
he
admin control the number of retries, though that's probably a bit excessive=
.

And don't tie it to CoCo VMs, e.g. if someone is relying on randomness for =
a bare
metal workload, they might prefer to panic if hardware is acting funky.