Received-SPF: pass (google.com: domain of linux-kernel+bounces-40306-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 15:57:58 +0000
From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>
Cc: Nikolay Borisov <nik.borisov@suse.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	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" <x86@kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Nakajima, Jun" <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-coco@lists.linux.dev>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Randomness on confidential computing platforms
Message-ID: <ZbPWht37uWZGhp4m@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20240126134230.1166943-1-kirill.shutemov@linux.intel.com>
 <6afe76be-90a7-4cf7-8c6c-23e6a14f8116@suse.com>
 <DM8PR11MB5750C6641F0951928E95439BE7792@DM8PR11MB5750.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DM8PR11MB5750C6641F0951928E95439BE7792@DM8PR11MB5750.namprd11.prod.outlook.com>
User-Agent: Mutt/2.2.12 (2023-09-09)

On Fri, Jan 26, 2024 at 03:42:12PM +0000, Reshetova, Elena wrote:
> > 
> > On 26.01.24 г. 15:42 ч., Kirill A. Shutemov wrote:
> > > 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.
> > 
> > But is this really a viable solution in the face of malicious VMM? It
> > assumes that if the VMM is signaled that randomness has been exhausted
> > it will try to rectify it, what if such a signal can instead be
> > repurposed for malicious purposes? Could it perhaps be used as some sort
> > of a side channel attack ?
> 
> The idea here is that it is not necessary VMM that is the cause why the
> RDRAND/RDSEED fails, so if this is the case, VMM can in theory do smth
> about the situation.
> 
> We have been thinking about if it can create an additional attack vector,
> but were not able to come with one. Do you have any in mind?

A guest might exit claiming failed RDRAND when in fact no such problem
occurred, as a way to mislead the host admin into taking action against
other guests.

If the CPU performance counters could report RDRAND exhaustion directly,
then the host admin could trust that information and monitor it, but the
host shouldn't rely on the (hostile) guest software to tell it about
exhaustion.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|