Re: [RFC] Randomness on confidential computing platforms

[Dave Hansen <dave.hansen@intel.com>]

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?