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]

Message-ID: <DM8PR11MB57503361808065E0DB669737E77D2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Tue, 30 Jan 2024 08:01:28 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, "Hansen, Dave"
	<dave.hansen@...el.com>
CC: 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>, 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



> -----Original Message-----
> From: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Sent: Monday, January 29, 2024 11:33 PM
> To: Hansen, Dave <dave.hansen@...el.com>
> Cc: 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; Theodore Ts'o <tytso@....edu>;
> Jason A. Donenfeld <Jason@...c4.com>; Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@...ux.intel.com>; Reshetova, Elena
> <elena.reshetova@...el.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-
> kernel@...r.kernel.org
> Subject: Re: [RFC] Randomness on confidential computing platforms
> 
> On Mon, Jan 29, 2024 at 01:04:23PM -0800, Dave Hansen wrote:
> > On 1/29/24 12:26, Kirill A. Shutemov wrote:
> > >>> Do we care?
> > >> I want to make sure I understand the scenario:
> > >>
> > >>  1. We're running in a guest under TDX (or SEV-SNP)
> > >>  2. The VMM (or somebody) is attacking the guest by eating all the
> > >>     hardware entropy and RDRAND is effectively busted
> > >>  3. Assuming kernel-based panic_on_warn and WARN_ON() rdrand_long()
> > >>     failure, that rdrand_long() never gets called.
> > > Never gets called during attack. It can be used before and after.
> > >
> > >>  4. 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. Userspace uses the failed RDRAND output to generate a key
> > >>  6. Someone exploits the horrible key
> > >>
> > >> Is that it?
> > > Yes.
> >
> > Is there something that fundamentally makes this a VMM vs. TDX guest
> > problem?  If a malicious VMM can exhaust RDRAND, why can't malicious
> > userspace do the same?

Let's be more concrete here: the main problem we are trying to fix here is
to make sure Linux RNG has entropy source(s) that are not under attacker control.
In case of userspace attacking kernel, yes, it can exhaust RDRAND/RDSEED,
but kernel has other entropy sources (interrupts) that are not under full userspace
control or fully observable. 
What makes the confidential VM story different is after VMM has exhausted
RDRAND/RDSEED, guest Linux RNG will fall back to the entropy sources that 
are under observance/control of VMM and this is what we try to avoid. 


> >
> > Let's assume buggy userspace exists.  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?

Good behaving userspace will ask for its cryptographic randomness from 
Linux RNG (some might do direct RDRAND/RDSEED calls, but most will
rely on Linux RNG). When it does ask for it, it is going to get a number
from it. The fact that that number doesn’t have adequate security is not
visible for userspace in any way. I don’t think anyone will go to dmesg and
check the warning logs to determine this. 
So, I don’t see how warning helps here in practice. 

Best Regards,
Elena