Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 29 Jan 2024 22:26:06 +0200 | From | "Kirill A. Shutemov" <> | Subject | Re: [RFC] Randomness on confidential computing platforms |
| |
On Mon, Jan 29, 2024 at 10:55:38AM -0800, Dave Hansen wrote: > 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.
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.
-- Kiryl Shutsemau / Kirill A. Shutemov
| ![\](/images/icornerr.gif) |