Received-SPF: pass (google.com: domain of linux-kernel+bounces-43529-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 29 Jan 2024 13:38:32 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
To: Dave Hansen <dave.hansen@intel.com>,
        "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>, 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>,
        "Kalra, Ashish" <ashish.kalra@amd.com>,
        Sean Christopherson <seanjc@google.com>, linux-coco@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC] Randomness on confidential computing platforms
User-Agent: K-9 Mail for Android
In-Reply-To: <CC681F94-469C-4225-A075-C5F9129E7D96@zytor.com>
References: <20240126134230.1166943-1-kirill.shutemov@linux.intel.com> <276aaeee-cb01-47d3-a3bf-f8fa2e59016c@intel.com> <dqiaimv3qqh77cfm2huzja4vsho3jls7vjmnwgda7enw633ke2@qiqrdnno75a7> <f5236e76-27d0-4a90-bde5-513ac9446184@intel.com> <dlhffyn7cccn5d4uvubggkrmtyxl4jodj5ukffafpsxsnqini3@5rcbybumab4c> <3a37eae3-9d3c-420c-a1c7-2d14f6982774@intel.com> <CC681F94-469C-4225-A075-C5F9129E7D96@zytor.com>
Message-ID: <CA4D4182-8D65-4CEB-A173-68B92B04641B@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On January 29, 2024 1:17:07 PM PST, "H=2E Peter Anvin" <hpa@zytor=2Ecom> wr=
ote:
>On January 29, 2024 1:04:23 PM PST, Dave Hansen <dave=2Ehansen@intel=2Eco=
m> wrote:
>>On 1/29/24 12:26, Kirill A=2E Shutemov wrote:
>>>>> Do we care?
>>>> I want to make sure I understand the scenario:
>>>>
>>>>  1=2E We're running in a guest under TDX (or SEV-SNP)
>>>>  2=2E The VMM (or somebody) is attacking the guest by eating all the
>>>>     hardware entropy and RDRAND is effectively busted
>>>>  3=2E Assuming kernel-based panic_on_warn and WARN_ON() rdrand_long()
>>>>     failure, that rdrand_long() never gets called=2E
>>> Never gets called during attack=2E It can be used before and after=2E
>>>=20
>>>>  4=2E Userspace is using RDRAND output in some critical place like ke=
y
>>>>     generation and is not checking it for failure, nor mixing it with
>>>>     entropy from any other source
>>>>  5=2E Userspace uses the failed RDRAND output to generate a key
>>>>  6=2E Someone exploits the horrible key
>>>>
>>>> Is that it?
>>> Yes=2E
>>
>>Is there something that fundamentally makes this a VMM vs=2E TDX guest
>>problem?  If a malicious VMM can exhaust RDRAND, why can't malicious
>>userspace do the same?
>>
>>Let's assume buggy userspace exists=2E  Is that userspace *uniquely*
>>exposed to a naughty VMM or is that VMM just added to the list of things
>>that can attack buggy userspace?
>
>The concern, I believe, is that a TDX guest is vulnerable as a *victim*, =
especially if the OS is being malicious=2E
>
>However, as you say a malicious user space including a conventional VM co=
uld try to use it to attack another=2E The only thing we can do in the kern=
el about that is to be resilient=2E
>
>Note that there is an option to the kernel to suspend boot until enough e=
ntropy has been gathered that predicting the output of the entropy pool in =
the kernel ought to be equivalent to breaking AES (in which case we have fa=
r worse problems=2E) To harden the VM case in general perhaps we should con=
sider RDRAND to have zero entropy credit when used as a fallback for RDSEED=
=2E
>

It is probably worth pointing out, too, that in reality the specs for RDRA=
ND/RDSEED are *extremely* sandbagged=2E The architect told me that it is ex=
tremely unlikely that we will *ever* see a failure due to exhaustion, even =
if it is executed continuously on all cores =E2=80=93 the randomness produc=
tion rate exceeds the bandwidth of the bus in uncore=2E