Received-SPF: pass (google.com: domain of linux-kernel+bounces-43513-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: Mon, 29 Jan 2024 13:17:07 -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: <3a37eae3-9d3c-420c-a1c7-2d14f6982774@intel.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>
Message-ID: <CC681F94-469C-4225-A075-C5F9129E7D96@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:04:23 PM PST, Dave Hansen <dave=2Ehansen@intel=2Ecom>=
 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 key
>>>     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*, e=
specially if the OS is being malicious=2E

However, as you say a malicious user space including a conventional VM cou=
ld try to use it to attack another=2E The only thing we can do in the kerne=
l about that is to be resilient=2E

Note that there is an option to the kernel to suspend boot until enough en=
tropy has been gathered that predicting the output of the entropy pool in t=
he kernel ought to be equivalent to breaking AES (in which case we have far=
 worse problems=2E) To harden the VM case in general perhaps we should cons=
ider RDRAND to have zero entropy credit when used as a fallback for RDSEED=
=2E