News for hackers. Stuff that matters.
Re:A months-old AMD microcode bug destroyed my weekend by zepearl on Tuesday October 29, 2019 @05:57PM (#21392535)
In the worst-case scenario of a lack of motherboard-update, to make things work during boot and later in Linux would it be enough to disable RANDOM_TRUST_CPU in the kernel source config ( https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.... ) (and/or using a kernel parameter in Grub), or would that make it unavailable only to the kernel itself but still available to other programs (e.g. systemd, wireguard, etc...)? If #2, are there any other parameters to completely disable it to then make programs fallback to kernel-based sources of entropy (disk activity, network, etc) to generate their random nbrs?
Re:A months-old AMD microcode bug destroyed my weekend by Dylan16807 on Tuesday October 29, 2019 @05:59PM (#21392555)
#2, as the article says. And no, unless you count running a hypervisor to hide the instruction.
Re:A months-old AMD microcode bug destroyed my weekend by zepearl on Tuesday October 29, 2019 @06:06PM (#21392602)
Thx :(
Re:A months-old AMD microcode bug destroyed my weekend by dfox on Tuesday October 29, 2019 @10:49PM (#21394250)
get_random_u32() which is the function in question uses RDRAND if ut is available regardless of what RANDOM_TRUST_CPU says. It is meant of fast source of “good enough entropy” for short lived secrets. Short circuiting to RDRAND arguably breaks the API contract, but when RDRAND actually produces random-ish values it is probably good enough.