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: <f5236e76-27d0-4a90-bde5-513ac9446184@intel.com>
Date: Mon, 29 Jan 2024 10:55:38 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.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>,
 Elena Reshetova <elena.reshetova@...el.com>,
 Jun Nakajima <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 1/29/24 08:41, Kirill A. Shutemov wrote:
> On Mon, Jan 29, 2024 at 08:30:11AM -0800, Dave Hansen wrote:
>> On 1/26/24 05:42, Kirill A. Shutemov wrote:
>>> 3. Panic after enough re-tries of RDRAND/RDSEED instructions fail.
>>>    Another DoS variant against the Guest.
>>
>> I think Sean was going down the same path, but I really dislike the idea
>> of having TDX-specific (or CoCo-specific) policy here.
>>
>> How about we WARN_ON() RDRAND/RDSEED going bonkers?  The paranoid folks
>> can turn on panic_on_warn, if they haven't already.
> 
> Sure, we can do it for kernel, but we have no control on what userspace
> does.
> 
> Sensible userspace on RDRAND/RDSEED failure should fallback to kernel
> asking for random bytes, but who knows if it happens in practice
> everywhere.
> 
> 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.
 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?