AMD finally submits kernel patch for broken RDRAND on older AMD APUs
It only took 5 years for AMD to submit a kernel patch which doesn't even fix RDRAND being broken on older AMD APUs after suspend. Their kernel patch "fixes" the problem by completely disabling the RDRAND instruction on all family 15 and 16 APUs and CPUs from AMD - even those not affected by this particular issue.
This has nothing to do with RDRAND being broken on 3000 series AMD CPUs. That issue is fixed by a BIOS update. Motherboard BIOS updates with the AMD AGESA firmware versioned 1003ABB or higher fixes the Ryzen 3000 CPUs failure to generate random data when RDRAND is called. Biostar made beta BIOSes with AGESA 1003ABB available on July 30th and ASUS made BIOS updates for their products available on August 12th.
AMD is now addressing older APUs like the E1-1200 and the E1-2500 which stops returning random values after the system has been suspended. This makes systemd versions from 240 to 242 freak out and make affected machines unusable after they have been suspended. There is a systemd patch for these versions and distributions like Fedora and Debian Buster have patched systemd versions in their repositories. This solved the immediately visible problems caused by the AMD RDRAND bug on these APUs but it never fixed the underlying problem.
AMD asset Tom Lendacky submitted a patch which makes the kernel as well as user-space programs believe that AMD family 15h and 16h APUs and CPUs don't support RDRAND at all on August 14th.
"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.
RDRAND support is indicated by CPUID Fn00000001_ECX[30]. This bit can be reset by clearing MSR C001_1004[62]. Any software that checks for RDRAND support using CPUID, including the kernel, will believe that RDRAND is not supported.
Update the CPU initialization to clear the RDRAND CPUID bit for any family 15h and 16h processor that supports RDRAND. If it is known that the family 15h or family 16h system does not have an RDRAND resume issue or that the system will not be placed in suspend, the "rdrand_force" kernel parameter can be used to stop the clearing of the RDRAND CPUID bit."
The obvious question is:
"You are the CPU vendor. Surely you can tell us how to init RDRAND in kernel if BIOS failed to do that... can you?"
It appears that AMD can't or won't share that information. It could be that nobody at AMD has it after all the years that have passed since the affected chips were designed. Actually fixing the bug would of course be preferable. AMD has instead opted to hide it with
+static void init_hide_rdrand(struct cpuinfo_x86 *c)
+{
+ /*
+ * The nordrand option can clear X86_FEATURE_RDRAND, so check for
+ * RDRAND support using the CPUID function directly.
+ */
+ if (!(cpuid_ecx(1) & BIT(30)) || rdrand_force)
+ return;
+
+ msr_clear_bit(MSR_AMD64_CPUID_FN_00000001, 62);
+ clear_cpu_cap(c, X86_FEATURE_RDRAND);
+ pr_info_once("hiding RDRAND via CPUID\n");
+}
if vendor = X86_VENDOR_AMD and family = 0x15 or family = 0x16.
AMDs proposed solution does work - but it is a solution which removes a feature which is partially broken instead of actually fixing the problem with it. It good that AMD is finally doing something half a decade after the affected products were released.
AMDs patch has of course not yet made it into the mainline kernel; it was proposed on the kernel mailing list yesterday and the standard review process does take some time. It will probably make it into the kernel eventually since this bug plaguing older AMD APUs does need a solution.
published 2019-08-15 - last edited 2019-08-15
Enable comment auto-refresher