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

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

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

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

[Duff~]

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

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

[PuckPoltergeist]

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.

So you can just enforce the rdrand capability, if you need it. What's the problem?

[pal666]

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.

lol, kernel can't produce random numbers without hardware. while patch is correct, you can't use kernel instead of hardware, you have to use some other hardware

[pal666]

What about Windows? Does the same issue occur there

same issue of non-random random numbers - yes, same issue of broken boot in systemd - no. i heard some game was broken

[pal666]

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.

but in our case user space did get it right and nothing would change by adding kernel middle man

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.

who are they?

[nranger]

Well...THAT sux !! So, I have a Lenovo Ideapad with a Mullins APU (Puma + cores which are orocess enhanced Jaguar cores) ...

I also have a Lenovo IdeaPad G35 (one of the Mullins APU machines) and for the $230 or so I paid for it, have been pretty happy with the performance. I'm amazed how well Firefox handles 50+ tabs on a 8Gb machine with a four core CPU designed for tablets and 2in1s.

That being said, my main issues with the machine are
(1) the plastics are shite -- all the screws in the bottom cover and in the ones in bottom case near the hinges sheared their inserts after a few 20" drops off the bed onto carpet,
(2) power/battery management is pretty "meh", new I was getting 5+ hours of life, now 11 months into my third battery it's under 2,
(3) GPU drivers -- I did switch to amdgpu from radeonsi around kernel 4.18 and it more or less worked, but various things have been broken then fixed so it's never perfect. Backlight control was busted for a while, HDMI audio has never really worked, the "DC" functions of the amdgpu driver seemed to work, and then Gnome stopped loading around kernel 5.1 and disabling DC fixed it.

Kind of annoying that my kernel cmdline changes almost every release. Now it includes "modprobe.blacklist=radeon amdgpu.ppfeaturemask=0xffffffff amdgpu.cik_support=1 amdgpu.si_support=1 amdgpu.dc=0 amdgpu.dpm=1"

In hindsight I probably should have just found a used Thinkpad X220 like all the Redhat devs used.