[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM8PR11MB5750C7D16DC566CD1329D5A5E77C2@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Wed, 31 Jan 2024 17:37:08 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Theodore Ts'o <tytso@....edu>, "Jason A. Donenfeld" <Jason@...c4.com>
CC: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, 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" <x86@...nel.org>, "Kuppuswamy
Sathyanarayanan" <sathyanarayanan.kuppuswamy@...ux.intel.com>, "Nakajima,
Jun" <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-coco@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
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_MOBmt6YAtncbbqP9LPK2dRjuO
> p1CrHzRA@...l.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.
I agree, this is probably the best we can do at the moment.
I did want to point out the runtime need of fresh entropy also, but
as we discussed in this thread we might not be able to get it
without introducing a DoS path for the userspace.
In this case, it is the best to only loose the forward prediction property
vs. the whole Linux RNG.
Best Regards,
Elena.
Powered by blists - more mailing lists