Zenbleed is coming for you baby!

gotnull

gotnull

Hello,

I just came across this sad news, it looks like we've got a new CPU situation, the guilty is AMD Zen 2.
Nope! this time disabling SMT will not be enough.

The list of the CPUs where the vulnerability was discovered:
AMD Ryzen 3000 Series Processors
AMD Ryzen PRO 3000 Series Processors
AMD Ryzen Threadripper 3000 Series Processors
AMD Ryzen 4000 Series Processors with Radeon Graphics
AMD Ryzen PRO 4000 Series Processors
AMD Ryzen 5000 Series Processors with Radeon Graphics
AMD Ryzen 7020 Series Processors with Radeon Graphics
AMD EPYC “Rome” Processors

AMD will release a patch to fix the problem ... in December 2023.
I guess I'll be very patient and pray to not be unlucky because I really don't want to try the workaround cpucontrol(8)(), it looks like a bit too risky.

Source:
https://lock.cmpxchg8b.com/zenbleed.html
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
https://www.tomshardware.com/news/z...t-from-amds-zen-2-processors-patches-released
en.wikipedia.org

Zen 2 - Wikipedia

en.wikipedia.org en.wikipedia.org
 
According to Theo de Raadt this primarily impacts OS that make heavy use of AVX instructions, e.g. Windows and glibc on Linux.
I don't know to what extent AVX instructions are used in base, but given that ports usually don't have AVX-optimizations enabled by default, I suspect this is also true for the base system.
 
gotnull said:
AMD will release a patch to fix the problem ... in December 2023.
I guess I'll be very patient and pray to not be unlucky because I really don't want to try the workaround cpucontrol(8)(), it looks like a bit too risky.

Source:
https://lock.cmpxchg8b.com/zenbleed.html
Click to expand...
The first source (link) tells us:

Solution​
​
We reported this vulnerability to AMD on the 15th May 2023.​
​
AMD have released an microcode update for affected processors. Your BIOS or Operating System vendor may already have an update available that includes it.​
​
Furthermore:
It is highly recommended to use the microcode update.​
...​
...​
FreeBSD​
On FreeBSD you would use cpucontrol(8).​

I do understand this, that on FreeBSD we may use cpucontrol(8) to update the CPU firmware which has been released already by AMD - note, this is one important purpose of cpucontrol. For the time being, Linux people need to set the chicken flags.

Where did you read, that AMD will fix the problem not until December 2023?
 
sko said:
According to Theo de Raadt this primarily impacts OS that make heavy use of AVX instructions, e.g. Windows and glibc on Linux.
I don't know to what extent AVX instructions are used in base, but given that ports usually don't have AVX-optimizations enabled by default, I suspect this is also true for the base system.
Click to expand...
I just had a look on the source of /usr/src/lib/libc/string/strlen.c of FreeBSD 13.2-RELEASE-p1. It does not use vector operations. There’s even no processor specific version. This maybe of advantage in the given case (for the time being), however, given that strlen() maybe one of the most called libc routnies, I find dislike this version, and for my all my x86 code am using a vectorized version since years, which is very similar to the zenbleed example code:
github.com

ContentCGI/utils.h at 57f8140c31a85f091fc665b33b12c5225f2ac335 · cyclaero/ContentCGI

Extensible FastCGI Daemon for FreeBSD. Contribute to cyclaero/ContentCGI development by creating an account on GitHub.
github.com github.com

This is a good example, because ContentCGI makes heavily use of the vectorized strvlen(), and quite a lot of times the strings for which it needs to know the lengths are more than a kB long. So doing it the old fashioned way, is somewhat less optimal, to say the least.
 
  • Thanks
Reactions: sko
cyclaero said:
AMD have released an microcode update for affected processors. Your BIOS or Operating System vendor may already have an update available that includes it.​
​
Furthermore:
It is highly recommended to use the microcode update.​
...​
...​
FreeBSD​
On FreeBSD you would use cpucontrol(8).​

I do understand this, that on FreeBSD we may use cpucontrol(8) to update the CPU firmware which has been released already by AMD - note, this is one important purpose of cpucontrol. For the time being, Linux people need to set the chicken flags.
Click to expand...
I read that differently. You use cpucontrol(8) to set the chicken flag on Freebsd. It is unrelated to the AMD microcode fix.
 
Jose said:
I read that differently. You use cpucontrol(8) to set the chicken flag on Freebsd. It is unrelated to the AMD microcode fix.
Click to expand...
That’s because of the difference between people being pre-emptively pessimistic compared to those pre-emptively optimistic. I tend to belong to the latter group of people.
 
cyclaero said:
I just had a look on the source of /usr/src/lib/libc/string/strlen.c of FreeBSD 13.2-RELEASE-p1. It does not use vector operations. There’s even no processor specific version. This maybe of advantage in the given case (for the time being), however, given that strlen() maybe one of the most called libc routnies, I find dislike this version, and for my all my x86 code am using a vectorized version since years, which is very similar to the zenbleed example code:
github.com

ContentCGI/utils.h at 57f8140c31a85f091fc665b33b12c5225f2ac335 · cyclaero/ContentCGI

Extensible FastCGI Daemon for FreeBSD. Contribute to cyclaero/ContentCGI development by creating an account on GitHub.
github.com github.com

This is a good example, because ContentCGI makes heavily use of the vectorized strvlen(), and quite a lot of times the strings for which it needs to know the lengths are more than a kB long. So doing it the old fashioned way, is somewhat less optimal, to say the least.
Click to expand...

I suspect this is mainly for increased compatibility with older CPUs; same as with port options where you usually have 4 choices: none, AVX, AVX2 and AVX512 (IIRC). Default is no AVX or other CPU optimizations, to make the packages as widely usable as possible on everything that might fall under 'amd64' architecture.
True, it's not the best performing way, but as one can see again and again with hardware security flaws like this one, being conservative is often the more secure way.
 
cyclaero said:
Where did you read, that AMD will fix the problem not until December 2023?
Click to expand...
It's from the second link, they called that "target date".
Depending on the CPU it may vary from October to December 2023, I probably should have be more precise I suppose, it's just that in my case it's December.
 
Did a good find :)

A nice rc script patches the CPU using cpuctl and cpucontrol, it also verifies the CPU Family before applying the patch which is a good measure, and if for some reason you changed your mind it is possible to go back by restoring the old value like it was before.

So the script belongs to the directory /usr/local/etc/rc.d/
Do not forget to make it executable chmod +x zenbleed_workaround
Add cpuctl_load="YES" to /boot/loader.conf
Add zenbleed_workaround_enable="YES" to /etc/rc.conf

To verify if the bit value changed, the following command read the content of the register CPU 0:
doas cpucontrol -m 0xc0011029 /dev/cpuctl0
After loading the script the last part changed from 0x10e08000 to 0x10e08200

During the boot I can see on the screen the message "Applying Zenbleed workaround for ...", but there is nothing in /var/run/dmesg.boot I suppose it is a normal behavior.

Obviously I am way over my head with this, the explanation given here are just what I could understand from the script and the man pages I've read.
If you want more details, I am sure some people here will be pleased to answer to your questions.

Thanks to this cool guy ;)

Sources:
cpuctl(4)()
cpucontrol(8)()
https://github.com/Freaky
gist.github.com

FreeBSD Zenbleed mitigation rc script

FreeBSD Zenbleed mitigation rc script. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com gist.github.com
 
cyclaero said:
That’s because of the difference between people being pre-emptively pessimistic compared to those pre-emptively optimistic. I tend to belong to the latter group of people.
Click to expand...
Turns out we're both right. The utility can be used both to engage the work-around, and to update the firmware. The best writeup I found on the latter is here:

Update Intel Microcode on FreeBSD - Thomas-Krenn-Wiki-en

FreeBSD provides support for updating the microcode of a processor at startup or at runtime. In this article, we use a server running FreeBSD 12.0 to show how to check the Intel Microcode version and how to install newer microcode versions if necessary.
www.thomas-krenn.com www.thomas-krenn.com

Based on that, I chose to go with Variant 1, updating loader.conf(5). Turns out the instructions from sysutils/devcpu-data are wrong for AMD CPUs. For me the magic incantation was
Code: 
cpu_microcode_load="YES"
cpu_microcode_name="/usr/local/share/cpucontrol/microcode_amd_fam17h.bin"

I found the path to the correct file by doing
Code: 
# kldload cpuctl
# cpucontrol -u /dev/cpuctl0
/usr/local/share/cpucontrol/microcode_amd_fam17h.bin: updating cpu /dev/cpuctl0 to revision 0x800820d... done.

And after all that... turns out my CPU is not affected, haha!
 
Jose said:
And after all that... turns out my CPU is not affected, haha!
Click to expand...
You know this from the microcode patch support list or reading AMD's affected processor list? Because the former hasn't been updated (or even created) to cover everything yet.
 
msplsh said:
You know this from the microcode patch support list or reading AMD's affected processor list? Because the former hasn't been updated (or even created) to cover everything yet.
Click to expand...
I looked at the Linux microcode patch.

kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel

git.kernel.org git.kernel.org

From that we see that these two models were patched
Code: 
Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes
Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
I can tell that I have a Family=0x17 Model=0x08 Stepping=0x02 because the firmware version 0x0800820d matches the cpucontrol(8) output.
 
You must log in or register to reply here.
Back
Top