Messages in this thread | | | Date | Wed, 31 Jan 2024 09:07:56 -0500 | From | "Theodore Ts'o" <> | Subject | Re: [PATCH 1/2] x86/random: Retry on RDSEED failure |
| |
What about simply treating boot-time initialization of the /dev/random state as special. That is, on x86, if the hardware promises that RDSEED or RDRAND is available, we use them to initialization our RNG state at boot. On bare metal, there can't be anyone else trying to exhaust the on-chip RNG's entropy supply, so if RDSEED or RDRAND aren't working available --- panic, since the hardware is clearly busted.
On a guest OS, if confidential compute is enabled, and if RDSEED and RDRAND don't work after N retries, and we know CC is enabled, panic, since the kernel can't provide the promised security gaurantees, and the CC developers and users are cordially invited to sharpen their pitchforks and to send their tender regards to the Intel RNG engineers.
For non-confidential compute guests, the question is what is the appropriate reaction if another VM, possibly belonging to a different user/customer, is carrying out a RDRAND DOS attack. I'd argue that in these cases, if the guest VM is using virtio-random, then the host's /dev/random should be able to cover for cases of Intel RNG exhaustion, and allowing other customer to be able to prevent other user's VM's from being able to boot is the the greater evil, so we shouldn't treat boot-time RDRAND/RDSEED failures as panic-worthy.
- Ted
| |