Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 31 Jan 2024 12:10:42 -0500 | From | "Theodore Ts'o" <> | Subject | Re: [PATCH 1/2] x86/random: Retry on RDSEED failure |
| |
On Wed, Jan 31, 2024 at 03:45:06PM +0100, Jason A. Donenfeld wrote: > On Wed, Jan 31, 2024 at 09:07:56AM -0500, Theodore Ts'o wrote: > > 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. > > This is the first thing I suggested here: https://lore.kernel.org/all/CAHmME9qsfOdOEHHw_MOBmt6YAtncbbqP9LPK2dRjuOp1CrHzRA@mail.gmail.com/ > > But Elena found this dissatisfying because we still can't guarantee new > material later.
Right, but this is good enough that modulo in-kernel RNG state compromise, or the ability to attack the underlying cryptographic primitives (in which case we have much bigger vulnerabilities than this largely theoretical one), even if we don't have new material later, the in-kernel RNG for the CC VM should be sufficiently trustworthy for government work.
> Yea, maybe bubbling the RDRAND DoS up to another DoS in the CoCo case is > a good tradeoff that will produce the right pitchforkers without > breaking anything real.
<Evil Grin>
- Ted
| ![\](/images/icornerr.gif) |