Re: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
On Thu, Aug 15, 2019 at 11:12:24AM -0400, Theodore Y. Ts'o wrote: > On Thu, Aug 15, 2019 at 01:24:35AM +0200, Pavel Machek wrote: > > 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! > > To be fair to AMD, I wouldn't call it a backdoor. Hanlon's razor is > applicable here: > > "Never attribute to malice that which can be adequately > explained by neglect." > > (Sometimes other words are used instead of neglect, but i'm trying to > be nice.) > Is it worth setting up a quirk for the Excavator era cpus, that triggers a call to rdseed on resume? Working under the assumption that calling rdseed would kick the rdrand instruction back into gear. Neil > > - Ted > > P.S. Also applicable: > > https://www.youtube.com/watch?v=XZxzJGgox_E >
Re: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
On Thu 2019-08-15 11:12:24, Theodore Y. Ts'o wrote: > On Thu, Aug 15, 2019 at 01:24:35AM +0200, Pavel Machek wrote: > > 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! > > To be fair to AMD, I wouldn't call it a backdoor. Hanlon's razor is > applicable here: > > "Never attribute to malice that which can be adequately > explained by neglect." > (Sometimes other words are used instead of neglect, but i'm trying to > be nice.) You are right, I thought it was returning values with low entropy, and it returns ~0 (so -- really really low entropy :-) and can't be clasified as a backdoor. Anyway, AMD is _not_ doing good job right now. I'd expect: a) CVE reference b) real fix; if BIOS can init the rng, so can kernel Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
On Thu, Aug 15, 2019 at 01:24:35AM +0200, Pavel Machek wrote: > 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! To be fair to AMD, I wouldn't call it a backdoor. Hanlon's razor is applicable here: "Never attribute to malice that which can be adequately explained by neglect." (Sometimes other words are used instead of neglect, but i'm trying to be nice.) - Ted P.S. Also applicable: https://www.youtube.com/watch?v=XZxzJGgox_E
Re: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
On 8/14/19 6:24 PM, Pavel Machek wrote: > On Wed 2019-08-14 21:17:41, Lendacky, Thomas wrote: >> From: Tom Lendacky >> >> 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? See this article: https://www.phoronix.com/scan.php?page=news_item&px=AMD-CPUs-RdRand-Suspend Thanks, Tom > >> >> +rdrand_force[X86] >> +On certain AMD processors, the advertisement of the >> +RDRAND instruction has been disabled by the kernel >> +because of buggy BIOS support, specifically around the >> +suspend/resume path. This option allows for overriding >> +that decision if it is known that the BIOS support for >> +RDRAND is not buggy on the system. > > But this is not how we normally deal with buggy BIOSes. We don't want > user to have to decide this... > > Should we introduce black-list or white-list of BIOS versions? > > Hmm. Actually. > > You are the CPU vendor. Surely you can tell us how to init RDRAND in > kernel if BIOS failed to do that... can you? > > Pavel >
Re: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
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
> >
> > 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
signature.asc
Description: Digital signature
