Received-SPF: pass (google.com: domain of linux-kernel+bounces-43552-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 29 Jan 2024 14:12:26 -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: <A9C23B76-490C-4DDA-A420-EA6F75E820EA@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
>

So as far as I understand, the uncore bus (at least at the time RDRAND/RDS=
EED was designed) is a single-transaction bus; once a read transaction has =
been accepted by the bus the bus is locked until the reply is sent (like PC=
I=2E) As such, the RNG unit simply doesn't have to option of not returning =
a response without holding the whole uncore bus locked=2E However, I believ=
e that if another core is waiting for the bus, that request will be served =
before the other core can return for more=2E

If the RNG bit source is crippled for some reason to the point of being ne=
ar failure, it is certainly possible for a livelock to happen, but at least=
 as far as I understand the likelihood of that happening enough to cause 16=
 failures in a row is so close to a total failure that it might be as well =
treated as one=2E

*Any* security sensitive application that doesn't take total RNG failure i=
nto account is fundamentally broken=2E *Any* hardware random number generat=
or is inherently an analog device, and as such has a nonzero probability of=
 failure=2E It has an integrity monitor, but all it can do is say "no" and =
not credit entropy, thereby slowing down and eventually stopping the unit (=
even RDRAND has a minimum seeding frequency guarantee, unlike /dev/urandom=
=2E)