RE: [PATCH v3] x86/coco: Require seeding RNG with RDRAND on CoCo systems

[Reshetova, Elena]

> On 2/21/24 09:19, Jason A. Donenfeld wrote:
> > On Wed, Feb 21, 2024 at 5:55 PM Dave Hansen <dave.hansen@xxxxxxxxx>
> 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
>