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

[btarunr]

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.



View at TechPowerUp Main Site

 

[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.

 

[xtreemchaos]

thankfully not Zen .

 

[ratirt]

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.

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.

 

[Vayra86]

Didn't Intel have an RNG bug as well a few years back? Seems like an allround oversight just like the Spectre issues.

 

[Redwoodz]

So this effects every Beema laptop being used? Sorry for those 2 people.

 

[R0H1T]

How do you lose (pseudo)randomness anyway

 

[Space Lynx]

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.

I have to admit this is a low for TPU... clicky clicky fishy fishy

 

[notb]

You 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.

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.

 

[Deleted member 158293]

Yeah this is click bait level stuff...

 

[notb]

How do you lose (pseudo)randomness anyway

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.

 

[eidairaman1]

If AMD takes this seriously they may provide a fix, who knows...

 

[Dave65]

So this effects every Beema laptop being used? Sorry for those 2 people.

LMAOOOOOOOO

 

[Vayra86]

How do you lose (pseudo)randomness anyway

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.

 

[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.

85911 – rdrand instruction fails after resume on AMD CPU

bugzilla.kernel.org

Definitely not recent.

 

[notb]

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.

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.

 

[R0H1T]

If 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.

1150286 – rdrand instruction fails after resume on AMD CPU

bugzilla.redhat.com

 

[bug]

Does anyone remember that Debian (and downstream) bug that wiped out software RNG? That one also went undetected for years.

 

[sorter]

Has anyone considered that systemd sucks?

 

[bug]

Has 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.

 

[R-T-B]

Didn'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.

Has anyone considered that systemd sucks?

It's against Unix philosophy, but to deny it has any benefits is pretty false.

We don't even know if this affects say Windows

If the hardware is faulty and an app uses it, of course it does.

software

Those openssl flags completely disable the use of rdrand. This is a purely hardware bug.

 

[R0H1T]

^Zenforo bug?

 

[R-T-B]

^Zenforo bug?

no idea, correcting...

EDIT: fixed. My post was duped all over if anyones curious.

 

[Jism]

those 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.

 

[R-T-B]

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.

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.