Re: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 2019-08-15 01:24:35, Pavel Machek wrote:
> On Wed 2019-08-14 21:17:41, Lendacky, Thomas wrote:
> > From: Tom Lendacky <thomas.lendacky@xxxxxxx>
> > 
> > There have been reports of RDRAND issues after resuming from suspend on
> > some AMD family 15h and family 16h systems. This issue stems from BIOS
> > not performing the proper steps during resume to ensure RDRAND continues
> > to function properly.
> 
> Burn it with fire!
> 
> I mean... people were afraid RDRAND would be backdoored, and you now
> confirm ... it indeed _is_ backdoored? /., here's news for you!
> 
> So what is the impact? Does it give random-looking but predictable
> numbers after resume? Does it give all zeros? Something else?

Plus... We trust the RDRAND in some configurations:

        random.trust_cpu={on,off}
				[KNL] Enable or disable trusting the
				use of the CPU's random
				number generator (if available) to
	       		     fully seed the
				kernel's CRNG. Default is controlled by
				CONFIG_RANDOM_TRUST_CPU.

so.. does this mean /dev/random was giving non-random values for some
users?

Certainly it means userland users were getting non-random values. That
sounds like something worth CVE and informing affected users?

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux