Wednesday, May 8th 2019

Some AMD Processors Have a Hardware RNG Bug, Losing Randomness After Suspend Resume

by
btarunr
 Discuss (27 Comments)
Red Hat Systemd (system and service manager) lead developer Lennart Poettering discovered that AMD A6-6310 "Beema" SoC that's popular among low-cost notebooks, has a faulty implementation of the RdRand random-number generation instruction. The processor's hardware random number generator (RNG) loses "randomness" after the machine resumes from a suspended state (i.e. waking up the notebook from sleep by opening its lid while it's powered on). Modern computers rely on RNGs for "entropy," critical to generation of unpredictable keys on the fly for SSL. However, the entropy source needn't be hardware, and isn't so by default. Software RNGs exist, and by default the Linux kernel does not use RdRand to generate entropy. Windows is not known to use RdRand for basic ACPI functions such as suspend/resume; however a faulty hardware RNG is not without implications for the platform, and applications that run on it.

Users on GitHub and Bugzilla report that with this bug, you cannot make a machine suspend a second time after waking it up from a suspended state, if your kernel uses RdRand. Commit cc83d51 to Systemd introduced optional randomness generation based on RdRand instruction. So, if RdRand instruction is present, it is used to generate UUIDs for invocation IDs. Michael Larabel of Phoronix comments that the RdRand bug is only found on older generations of AMD processors, "Excavator" and older; and does not affect the latest "Zen" processors. This bug report chronicles what's wrong with RdRand on the affected processors, as does this Linux kernel bugzilla thread. By avoiding RdRand usage on the system as part of generating a UUID, the reported systemd issue no longer happens. Red Hat is working on a solution to this bug.
Source: Phoronix

Related News

Add your own comment

27 Comments on Some AMD Processors Have a Hardware RNG Bug, Losing Randomness After Suspend Resume

#1
nemesis.ie
Maybe adjust the title to something like "Some older (2014) AMD tablet SoCs ....".

That would be a bit less "attention grabbing" though I suppose. ;)

Let's hope they bring out a microcode update quickly.

It's also odd that this appears to have been first reported in 2014 and it's only being worked on now? Maybe it's a non-issue (per the comments) as most of this stuff is now in software/windows doesn't use it. So why have the Linux folks just decided to do an update/fix for it recently? Strange.
Posted on Reply
#3
ratirt
nemesis.ieMaybe adjust the title to something like "Some older (2014) AMD tablet SoCs ....".

That would be a bit less "attention grabbing" though I suppose. ;)

Let's hope they bring out a microcode update quickly.

It's also odd that this appears to have been first reported in 2014 and it's only being worked on now? Maybe it's a non-issue (per the comments) as most of this stuff is now in software/windows doesn't use it. So why have the Linux folks just decided to do an update/fix for it recently? Strange.
True that. I thought Ryzen is affected as well.
You think they are going to do something with this? I mean, Ryzen going to replace these older AMD products anyway.
Posted on Reply
#4
Vayra86
Didn't Intel have an RNG bug as well a few years back? Seems like an allround oversight just like the Spectre issues.
Posted on Reply
#5
Redwoodz
So this effects every Beema laptop being used? Sorry for those 2 people. :wtf:
Posted on Reply
#6
R0H1T
How do you lose (pseudo)randomness anyway :wtf:
Posted on Reply
#7
Space Lynx
Astronaut
nemesis.ieMaybe adjust the title to something like "Some older (2014) AMD tablet SoCs ....".

That would be a bit less "attention grabbing" though I suppose. ;)

Let's hope they bring out a microcode update quickly.

It's also odd that this appears to have been first reported in 2014 and it's only being worked on now? Maybe it's a non-issue (per the comments) as most of this stuff is now in software/windows doesn't use it. So why have the Linux folks just decided to do an update/fix for it recently? Strange.
I have to admit this is a low for TPU... clicky clicky fishy fishy
Posted on Reply
#8
notb
ratirtYou think they are going to do something with this? I mean, Ryzen going to replace these older AMD products anyway.
They have to. Computing is not just gaming desktops. :-P

There are embedded chips on this arch running a lot of hardware. How would you feel taking money from an ATM, if you know it may have faulty encryption? ;-)
These embedded chips will work for many years (hopefully).

If we searched long enough, I'm sure we'd find trains or planes using these chips as well.
Posted on Reply
#10
notb
R0H1THow do you lose (pseudo)randomness anyway :wtf:
The idea behind RdRand is that it returns "true" random numbers, i.e. there's no cycle.
Thing is: Intel implemented this first and introduced and instruction set that got popular. AMD made a workaround, computation-based implementation (so not really random, but still extremely good). Problem is: people found a situation when this algorithm breaks and RNG quality drops significantly.

Zen uses an entropy-based implementation similar to Intel's, so it isn't affected by this issue.
Posted on Reply
#11
eidairaman1
The Exiled Airman
If AMD takes this seriously they may provide a fix, who knows...
Posted on Reply
#12
Dave65
RedwoodzSo this effects every Beema laptop being used? Sorry for those 2 people. :wtf:
LMAOOOOOOOO:laugh::laugh::laugh::laugh:
Posted on Reply
#13
Vayra86
R0H1THow do you lose (pseudo)randomness anyway :wtf:
Don't you remember from way back in the day, walkmans and discmans had a 'Random' play feature with recognizable patterns? I owned quite a few and they all had that - but maybe I'm just weird noticing that in the first place. It wasn't fixed up to the point that I could tell what song came next, but it definitely had similar 'jumps' through the song lists every so often. Play enough songs and it doesn't feel so random anymore.
Posted on Reply
#14
R0H1T
This seems to be a very specific problem - Linux, OpenSSL, resume from sleep, older gen hardware. You need to tick a lot of boxes to get affected by this software bug.
After suspend/resume on a recent AMD CPU, the rdrand instruction fails.
symptoms are that openssl fails to generate keys (trying to do kernel
module signing), and ssh anywhere does not work.

The problem was eventually diagnosed by disabling that instruction in ssh - i.e. "OPENSSL_ia32cap=~0x4000000000000000 ssh ..." works.
bugzilla.kernel.org/show_bug.cgi?id=85911

Definitely not recent.
Posted on Reply
#15
notb
R0H1TThis seems to be a very specific problem - Linux, OpenSSL, resume from sleep, older gen hardware. You need to tick a lot of boxes to get affected by this software bug.
Not exactly true. Hardware RNGs are used in many other situations. Scientists love them. It was an amazing leap when Intel added this in Ivy.
In case you wonder where scientists got random numbers earlier: they ordered them. For money.

Entropy-based implementations in CPUs are rather good, just very slow. A fast quantum-based RNG costs $1000.

If AMD's workaround (before Zen it was not a true hardware RNG, just a boosted pseudo) is faulty and there's a chance of a problem in some critical applications (embedded!), it has to be fixed or killed.
Posted on Reply
#16
R0H1T
notbIf AMD's workaround (before Zen it was not a true hardware RNG, just a boosted pseudo) is faulty
Sure, however this bug was first reported back in 2014 but was closed due to insufficient data. I guess the guy suffering from it, instead suffered more from the craptop? We don't even know if this affects say Windows, also Linux doesn't use just the hardware RNG for entropy.

bugzilla.redhat.com/show_bug.cgi?id=1150286
Posted on Reply
#17
bug
Does anyone remember that Debian (and downstream) bug that wiped out software RNG? That one also went undetected for years.
Posted on Reply
#19
bug
sorterHas anyone considered that systemd sucks?
Everything sucks, but systemd sucks a little less than sysv init.
I don't particularly love systemd, but it works and it adds value.
Posted on Reply
#20
R-T-B
Vayra86Didn't Intel have an RNG bug as well a few years back? Seems like an allround oversight just like the Spectre issues.
Link? I am unaware of any active issues in Intel's implementation.
sorterHas anyone considered that systemd sucks?
It's against Unix philosophy, but to deny it has any benefits is pretty false.
R0H1TWe don't even know if this affects say Windows
If the hardware is faulty and an app uses it, of course it does.
R0H1Tsoftware
Those openssl flags completely disable the use of rdrand. This is a purely hardware bug.
Posted on Reply
#22
R-T-B
R0H1T^Zenforo bug?
no idea, correcting...

EDIT: fixed. My post was duped all over if anyones curious.
Posted on Reply
#23
Jism
Redwoodzthose 2
It would suprise you how many casino's over the world use embedded hardware from AMD. I dont see a slot machine for example go into a sleep state after being inactive (they just turn it off) but it could affect that same Randomness games are supposed to have.
Posted on Reply
#24
R-T-B
JismIt would suprise you how many casino's over the world use embedded hardware from AMD. I dont see a slot machine for example go into a sleep state after being inactive (they just turn it off) but it could affect that same Randomness games are supposed to have.
When it's important to have reliable noncompromisable entropy on the cheap they usually generate it via software. Rdrand is considered potentially weak in such cases.
Posted on Reply
#25
AzraeiHalim
I have laptop AMD Richland A8-5550M back in the day but I don't have any problem from wakeup the laptop from sleep.
Posted on Reply
Add your own comment
Nov 18th, 2024 20:26 EST change timezone

Latest GPU Drivers

New Forum Posts

Popular Reviews

Controversial News Posts