AMD Bulldozer/Jaguar CPUs Will No Longer Advertise RdRand Support Under Linux

[Jumbotron]

Well...THAT sux !! So, I have a Lenovo Ideapad with a Mullins APU (Puma + cores which are orocess enhanced Jaguar cores) and a Lenovo Ideapad with a Bristol Ridge APU (process enhanced Carrizo APU which, in turn, is based on Excavator cores which are in turn based on Bulldozer. I've never had issues with either laptop concerning wake from sleep or suspend operations but everyone's mileage varies. What DOUBLE sucks is for my Mullins APU I'm STILL having to load the Radeon driver and not AMDGPU even though for years AMD has promised to support GCN 1.1 Sea Island GPUs. So now to read that this power issue is being sweeped under the rug as well is disappointing.

[Duff~]

Right in the 'AMD support is excellent for Linux' meme.

[xorbe]

Having rdrand even user visible was a mistake in the first place [...] User space always seems to get it wrong.

Turns out there are video games using rdrand for random numbers ... this is HORRIBLE, rdrand is a slow, cryptographically secure source of random numbers. Games are blowing 1500-2500 cycles to get a simple random number.

RDRAND literally is spec'ed to return crap in certain circumstances and you're supposed to detect that and work around it, but does anything? No, they just blindly trust that it works. Yeah, don't ever check return codes, folks. Let's see how well that works.

Problem is that the return code was good, but the data was not.

[jakubo]

There is so much proprietary in intel architecture cpu's, it's hard to have a coreboot on a recent CPU.
It's not like it used to be. These days you have to sign a number of NDA's to only get an AMD or intel to boot. CPU's are now started by their "security processors".

are we still talking about bulldozer architecture..?

[willmore]

The real question is: does windows use it at all?
On Linux, unless explicitly used, RdRand just should go on a pile of entropy served by the kernel, because we really don't trust these kind of "trust us it is really random" generators. So random values in the linux kernel are never determined by RdRand. Ever. So even if it just returns -1, it does not matter.
It does matter however if applications use it directly. So the patch of AMD is correct, it actually says: do not rely on this hardware, use the linux kernel instead.

Having rdrand even user visible was a mistake in the first place. Only the kernel should be handling that. User space always seems to get it wrong. RDRAND literally is spec'ed to return crap in certain circumstances and you're supposed to detect that and work around it, but does anything? No, they just blindly trust that it works. Yeah, don't ever check return codes, folks. Let's see how well that works.

[Ardje]

So would Coreboot be a solution, if it was ready to replace BIOS for these particular CPUs /laptops? Maybe an opportunity to shine...

There is so much proprietary in intel architecture cpu's, it's hard to have a coreboot on a recent CPU.
It's not like it used to be. These days you have to sign a number of NDA's to only get an AMD or intel to boot. CPU's are now started by their "security processors".

[Ardje]

Typo:

What about Windows? Does the same issue occur there, or did they work around it?

The real question is: does windows use it at all?
On Linux, unless explicitly used, RdRand just should go on a pile of entropy served by the kernel, because we really don't trust these kind of "trust us it is really random" generators. So random values in the linux kernel are never determined by RdRand. Ever. So even if it just returns -1, it does not matter.
It does matter however if applications use it directly. So the patch of AMD is correct, it actually says: do not rely on this hardware, use the linux kernel instead.

[Hibbelharry]

Once again, shoddy Linux support from AMD who are more interested in disabling these features or covering them up, rather than standing by users. Once again, lower confidence in AMD's Linux support.

Did you get that AMD is just one small part in the solution chain?

They're releasing a CPU, microcode, some other smal pieces. They sell that stuff to OEMs, which are sourcing accompanying hardware and software (bios,...) from other vendors. Then they're blending and glueing all that stuff together. After all, PCs are a modular system. All these glue and blend steps will yield additional bugs, all the time. If you want to get rid of a bug, a lot of groups have to work together. If one group doesn't care, you're out of luck.

Part of this equation:
If AMD did do all things right and the OEM does something wrong, that's simply not AMDs fault. You should contact your OEM and blame them. If the OEM states your usecase (linux, dish washing, whatever) isn't supported, you are out of luck.

And:
If vendors decide to do their own stuff, like not validating linux due to cost or relevance, or to give customers "unique USPs" like advertising PCIE 4.0 (recent example, AMD did announce before no vendor should do that for old chipset based motherboards...)... that's your OEMs fault.

[jakubo]

So would Coreboot be a solution, if it was ready to replace BIOS for these particular CPUs /laptops? Maybe an opportunity to shine...

[rene]

IMHO it is unacceptable that this took so long (years!) and is not even properly fixed in BIOS / microcode. Just switching an previously advertised features of is not a fix.