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]
Date: Thu, 22 Feb 2024 07:35:21 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "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 v3] x86/coco: Require seeding RNG with RDRAND on CoCo
 systems


> On 2/21/24 09:19, Jason A. Donenfeld wrote:
> > On Wed, Feb 21, 2024 at 5:55 PM Dave Hansen <dave.hansen@...el.com>
> wrote:
> >> On 2/21/24 04:32, Jason A. Donenfeld wrote:
> >>> +__init void cc_random_init(void)
> >>> +{
> >>> +     unsigned long rng_seed[32 / sizeof(long)];
> >> My only nit with this is the magic "32".
> >>
> >> Why not 16?  Or 64?
> > 32 bytes = 256-bits = what we're targeting. Very normal thing to see
> > places in the RNG, used all over random.c and lots of platform
> > drivers. Pretty obvious and straightforward to anyone familiar with
> > this kind of code. Not the kind of thing you'd want to replace with
> > some abstracted constant that makes you search.
> 
> OK, so we're trying to get 256 bits of seed data from RDRAND?
> 
> There's an entire section of the Intel whitepaper[1]: "Generating Seeds
> from RDRAND".  It describes one "method of turning 512 128-bit samples
> from the DRNG into a 128-bit seed value".  I was naively thinking that
> if the kernel wants 256 bits of seed data from RDRAND, it might take
> 2*(512 128-bit samples).

Yes, this would be a proper way of doing it in the absence of 100% entropic
seed from RDSEED, but this guidance doesn’t quite
apply in Linux RNG case since we are not really able to seed ChaCha PRNG
directly anyhow with the input from RDRAND: we are only allowed to 
contribute to the entropy pool. If you want to properly follow 
NIST standards on DRNGs (SP800-90A/B/C), we have many non-compliancy
issues in Linux RNG even without the CoCo case. Solving this while taking
into account people's fears about RDRAND/RDSEED trustworthiness is not
easy. 

Best Regards,
Elena.

> 
> I'm not suggesting that we use the exact construction from that
> whitepaper, but I'm reasonably sure I could actually explain to someone
> where a magic 1024 came from.
> 
> I also went through a smattering of add_device_randomness() users.  I
> didn't see much of a pattern there that seemed to line up with a
> 256-bits convention.  If anything they seemed to just use what they had
> laying around.  I saw byte counts of 16, 21, 12, 8, 1, strlen(), 56.
> But no pattern I could discern.  Did you mean something different by
> "platform drivers"?
> 
> If we're going to have arch/x86-specific crud, it would be great to make
> it obvious and straightforward to those of us simple folk that are
> familiar with arch/x86 code.
> 
> 1.
> https://www.intel.com/content/www/us/en/developer/articles/guide/intel-
> digital-random-number-generator-drng-software-implementation-guide.html
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ