AMD Bulldozer/Jaguar CPUs Will No Longer Advertise RdRand Support Under Linux
Not directly related to the recent AMD Zen 2 BIOS update needed to fix an RdRand problem (though somewhat related in that the original systemd bug report for faulty AMD RdRand stems from these earlier CPUs), but AMD has now decided to no longer advertise RdRand support for Family 15h (Bulldozer) and Family 16h (Jaguar) processors under Linux.
The RdRand instruction will still work on capable CPUs, but the CPU ID bit is being cleared so that it won't be advertised for software explicitly checking for the support. Tom Lendacky of AMD resorted to clearing the RDRAND CPU ID bit for 15h/16h processors (no impact for Zen, etc) due to RdRand issues cropping up after suspend/resume. Those issues have affected some users for a while and originate with the original AMD RdRand systemd bug report over problems following that cycle.
The buggy RdRand is being blamed on BIOS implementations not carrying out the proper steps for ensuring RdRand continues to function. But with apparently enough faulty BIOS out there, the RdRand bit will now be cleared for those CPUs to try to stop software from using it -- though any software still doing so, can though could experience the problematic events. The bug has been known for at least five years though only now being acted upon where RdRand could effectively be returning just -1.
If you don't plan to suspend/resume or your system/BIOS is known to be in a good state, there is a new rdrand_force kernel parameter being added to force-enable this support (a.k.a. maintain the status quo).
In response, at least one upstream developer is causing this a security vulnerability that up until now the RdRand could be spewing non-random data and an issue with AMD's RdRand implementation that it could be insecure if not properly programmed by the BIOS.
This change is currently pending via this patch that is likely to end up in the Linux 5.4 cycle though no word yet on the stable back-port outlook.
The RdRand instruction will still work on capable CPUs, but the CPU ID bit is being cleared so that it won't be advertised for software explicitly checking for the support. Tom Lendacky of AMD resorted to clearing the RDRAND CPU ID bit for 15h/16h processors (no impact for Zen, etc) due to RdRand issues cropping up after suspend/resume. Those issues have affected some users for a while and originate with the original AMD RdRand systemd bug report over problems following that cycle.
The buggy RdRand is being blamed on BIOS implementations not carrying out the proper steps for ensuring RdRand continues to function. But with apparently enough faulty BIOS out there, the RdRand bit will now be cleared for those CPUs to try to stop software from using it -- though any software still doing so, can though could experience the problematic events. The bug has been known for at least five years though only now being acted upon where RdRand could effectively be returning just -1.
If you don't plan to suspend/resume or your system/BIOS is known to be in a good state, there is a new rdrand_force kernel parameter being added to force-enable this support (a.k.a. maintain the status quo).
In response, at least one upstream developer is causing this a security vulnerability that up until now the RdRand could be spewing non-random data and an issue with AMD's RdRand implementation that it could be insecure if not properly programmed by the BIOS.
This change is currently pending via this patch that is likely to end up in the Linux 5.4 cycle though no word yet on the stable back-port outlook.
24 Comments