Received-SPF: pass (google.com: domain of linux-kernel+bounces-43632-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 29 Jan 2024 15:32:52 -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: <b3f48f9c-c1c0-47b5-b55a-d9cd63d86951@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> <v6maadzwtke3z5ejp2mavsnm4mvmjbu7demvldzpobqeva74rx@r6y5fwxsyoep> <b3f48f9c-c1c0-47b5-b55a-d9cd63d86951@intel.com>
Message-ID: <5861735E-8DE0-42D4-B7CE-E69F129CA7C8@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On January 29, 2024 2:18:50 PM PST, Dave Hansen <dave=2Ehansen@intel=2Ecom>=
 wrote:
>On 1/29/24 13:33, Kirill A=2E Shutemov wrote:
>>> 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 thin=
gs
>>> that can attack buggy userspace?
>> This is good question=2E
>>=20
>> VMM has control over when a VCPU gets scheduled and on what CPU which
>> gives it tighter control over the target workload=2E It can make a
>> difference if there's small window for an attack before RDRAND is
>> functional again=2E
>
>This is all a bit too theoretical for my taste=2E  I'm fine with doing
>some generic mitigation (WARN_ON_ONCE(hardware_is_exhausted)), but we're
>talking about a theoretical attack with theoretical buggy software when
>in a theoretically unreachable hardware state=2E
>
>Until it's clearly much more practical, we have much bigger problems to
>worry about=2E

Again, do we even have a problem with the "hold the boot until we have ent=
ropy"option?