linux-kernel - RE: [PATCH v2 2/2] x86/coco: Require seeding RNG with RDRAND on CoCo systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM8PR11MB5750FFAC83A7899DC2A5EBBAE7572@DM8PR11MB5750.namprd11.prod.outlook.com>
Date: Wed, 21 Feb 2024 07:52:30 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Jason A. Donenfeld" <Jason@...c4.com>
CC: "x86@...nel.org" <x86@...nel.org>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Borislav Petkov <bp@...en8.de>,
	Daniel P . Berrangé <berrange@...hat.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar
	<mingo@...hat.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
	Theodore Ts'o <tytso@....edu>, Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [PATCH v2 2/2] x86/coco: Require seeding RNG with RDRAND on CoCo
 systems

> Hi Elena,
> 
> On Fri, Feb 16, 2024 at 8:57 AM Reshetova, Elena
> <elena.reshetova@...el.com> wrote:
> > So, yes, coco_random_init() happens first, which actually now has a nice
> > side-effect that on coco platforms we drop HW CPU output even earlier
> > in the entropy pool (Yay!).
> > Which at this point would be almost perfect, *if* we could also
> > count this entropy drop and allow ChaCha seeding to benefit straight from
> > this early drop of entropy.
> 
> I addressed this already in my last reply. I wouldn't get too hung up
> on the entropy counting stuff. The RNG is going to get initialized
> just fine anyway no matter what, and whether or not it's counted,
> it'll still be used and available basically immediately anyway.
> 
> > How about changing this to use add_hwgenerator_randomness()?
> 
> That function is only for the hwrng API. It handles sleep semantics
> and that's specific to that interface boundary. It is not for random
> drivers and platforms to call directory.
> 
> > And adjust cc_random_init() to try rdseed first and only fallback to rdrand
> > if it fails?
> 
> I guess that's possible, but what even is the point? I don't think
> that really more directly accomplishes the objective here anyway. The
> whole idea is we want to ensure that RDRAND is at least working for 32
> bytes and if not panic. That's *all* we care about. Later on the RNG
> will eat rdseed opportunistically as it can; let it handle that as it
> does, and leave this patch here to be simple and direct and accomplish
> the one single solitary goal of panicking if it can't avoid the worst
> case scenario.


Okay, I guess I won’t start fighting for a cleanliness of an overall construction
(and rest of people stay pretty quiet in this discussion thread). 
Functionally-wise we will get what we need in practice and I learned that
"disagree and commit" is a very useful principle to exercise for moving things forward,
so I am ok with this approach.

Would you submit the patch or how do we proceed on this? 

Best Regards,
Elena.