linux-kernel - RE: [RFC] Randomness on confidential computing platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 26 Jan 2024 15:42:12 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Nikolay Borisov <nik.borisov@...e.com>, "Kirill A. Shutemov"
	<kirill.shutemov@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>, Theodore Ts'o <tytso@....edu>, "Jason A.
 Donenfeld" <Jason@...c4.com>
CC: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
	"Nakajima, Jun" <jun.nakajima@...el.com>, Tom Lendacky
	<thomas.lendacky@....com>, "Kalra, Ashish" <ashish.kalra@....com>, "Sean
 Christopherson" <seanjc@...gle.com>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [RFC] Randomness on confidential computing platforms

> 
> 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? 

Best Regards,
Elena.