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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ