sticklyman

Ah, yes. That makes sense. I definitely want to run it earlier, but just didn't understand enough about the unraid boot process to know how to best do that. Cheers! I have also just confirmed that this does seem to stop the zenbleed POC (I'll leave it running for some hours to be sure).

Thanks a lot for reminding me of this. I knew of MSR tools and just saw that intel had archived them - I'd mistakenly assumed they no longer worked. I can confirm that I was able to get wrmsr and rdmsr to work on unraid. I ended up building the two binaries statically: gcc -static -o wrmsr wrmsr.c gcc -static -o rdmsr rdmsr.c I did this on a different machine and transferred them across. Note that they can't reside in /boot as that is vfat and therefore doesn't support direct execution. For now, I've tested this with the binaries on my cache drive, and have set up a user script to run the above command "At First Array Start Only". My script is the following: #!/bin/bash echo "About to battle the Spectral Chicken. Value before the battle:" /mnt/fastcache/rdmsr -c 0xc0011029 /mnt/fastcache/wrmsr -a 0xc0011029 $(($(/mnt/fastcache/rdmsr -c 0xc0011029) | (1<<9))) echo "The battle is over. Did we beat the Spectral Chicken? (The value should have the DE_CFG[9] bit set)" /mnt/fastcache/rdmsr -c 0xc0011029 And the result is the following on my system: About to battle the Spectral Chicken. Value before the battle: 0x3000310e08002 The battle is over. Did we beat the Spectral Chicken? (The value should have the DE_CFG[9] bit set) 0x3000310e08202 I have (so far at least) not confirmed if this stops the exploit or not, but having the bit set certainly makes me happier at the moment. Do you have a recomendation for where to put the rdmsr/wrmsr binaries such that they are both persistent across boot and available when the config/go script is executed?

Update: Looks like AMD has only released the microcode fix for the Epyc CPUs and the rest are not coming until much later in the year. There is now a Linux kernel patch which effectively sets the chicken bit if the vulnrability has not been patched. Probably makes sense to cherry-pick this patch into the unraid kernel if it hasn't been backported already (seems to be in Linux 6.1.41, for example).

Today the Zenbleed vulnrability has been made public, which allows data to be extracted from the YMM, etc, registers on a set of AMD Zen2 architecture CPUs. The high-level summary is that this requires either a microcode update (preferred), or a chicken bit to be set (not preferred due to performance hit). The microcode update has seemingly been released by AMD already, but it will take time for motherboard vendors to propagate this to the BIOS/UEFI. Considering that there are some relatively old CPUs affected, I can see some motherboard vendors not shipping the update. Is there a plan to update the kernel shipped with unraid to include this microcode update? If so, when? Thanks!

Fantastic. I can confirm that things look correct now. Thanks so much for fixing it!

Hi. Thanks for creating this plugin! It looks like the most recent version of the pluigin has the wrong ownerships set, and is hence changing the ownership of /, /usr, etc to printer:1000 (in my case at least). The result is that things like SSHing into the unraid server with a keyfile no longer work, for example. File ownerships should be root:root (I believe) for / and /usr. A temporary fix (for anyone else who faces this issue) is to run the following commands: # Don't recursively apply to / because we don't want to clobber permissions on /mnt!!! chown root:root / chown root:root -R /usr Please fix this in the plugin, thanks