On Tue Jul 25, 2023 at 6:30 PM UTC, Jeffrey Walton wrote: On Tue, Jul 25, 2023 at 2:14 PM Demi Marie Obenour <demi () invisiblethingslab com> wrote: On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. Related, Ubuntu released an updated amd64-microcode around (or before) 1:45 PM EST today. My Ubuntu machines have already been patched.
I was kind of surprised to see how quickly it landed. the updated amd64-microcode only contains the fixes published to linux-firmware, which only affects epyc cpus, as noted. unless you're running epyc cpus (which is slightly unlikely so i thought i'd mention it, but apologies if that is indeed the case) you didn't actually receive any fix.
the latest kernel released today sets the chicken bit if no patched ucode is loaded which also works to mitigate the issue. (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98)
you can test this by running the zenbleed reproduction, from https://cmpxchg8b.com/files/zenbleed-v5.tar.gz
(if it outputs anything, you're vulnerable) Jeff
On Tue, Jul 25, 2023 at 2:14 PM Demi Marie Obenour <demi () invisiblethingslab com> wrote: On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. Related, Ubuntu released an updated amd64-microcode around (or before) 1:45 PM EST today. My Ubuntu machines have already been patched.
I was kind of surprised to see how quickly it landed.
Jeff
OS vendors can include it in microcode updates just fine assuming the change is minor (Spectre/Meltdown did take quite some time to iron out stability to live patch it). On 25 Jul 2023, at 19:58, Demi Marie Obenour <demi () invisiblethingslab com> wrote:
On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
On Tue, Jul 25, 2023 at 06:12:44PM +0100, Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. Does AMD make OS-loadable μcode patches available for client platforms, or must all μcode loading on clients be done by the firmware? If the latter, then it will take a very long time for clients to get patched, even if AMD released the updates promptly. Also, server platforms can usually reflash the firmware via the BMC, but client platforms do not have this option. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Eddie Chapman wrote: alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows. According to the writeup [1] in Google's security repo "AMD unexpectedly published patches" and was then forced to agree on an earlier disclosure date.
Mistakes happens to everyone...
[1] https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed
alice wrote: this is a disaster of a security announcement from AMD. nothing is fixed except for epyc. the only workaround anyone really has is the chicken bit, thankfully. Yes, very disappointing. Pure speculation; perhaps they were planning on disclosing at the end of the year with full set of Microcode ready but something we don't know (yet) forced them to disclose early. Who knows.
Very unscientific and limited test but I just compiled qemu 7.2.4 on a gentoo workstation with a Ryzen 7 3700X (Zen 2) running linux kernel 5.15.119. Took 5 min 37s. Rebooted into 5.15.122 with the chicken bit fix (confirmed in dmesg appears to be applied), compiled qemu again, this time it took 5 min 25s. So my initial impression is the chicken bit fix is fine in general but remains to be seen if certain workloads significantly impacted I guess.
On Mon, Jul 24, 2023 at 01:41:36PM -0400, Marc Deslauriers wrote: Hi,
There seems to be confusion regarding which is the correct commit:
Your blog post says it's 0bc3126c9cfa0b8c761483215c25382f831a7c6f which is for family 17h.
This post says it's b250b32ab1d044953af2dc5e790819a7703b7ee6 which is for family 19h.
I assume the 17h family one is the correct one?
Thanks,
Marc. Yes, but it by no means covers all zen 2 models. See amd-ucode/README
Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
17-31-00 Rome/Castle Peak 0x0830107a 17-a0-00 Mendocino 0x08a00008
Models missing include:
17-60-01 Renoir 0x0860010b 17-68-01 Lucienne 0x08608105 17-71-00 Matisse 0x08701032 17-90-02 Van Gogh
The known good patch levels are used by xen and linux. But the microcode for Renoir, Lucienne and Matisse is not available as far as I can tell.