Zenbleed - CVE-2023-20593

[reflect]

If it's indeed browser Javascript executable, that would be indeed a whole different story.

I'm a bit skeptical about that claim, not only because it wasn't backed up, but also because it would be incredibly negligent by AMD to not patch this on consumer devices before going public. It would mostly affect ordinary computers though, I don't think a lot of homelabbers visit websites and run random Javascript on their Proxmox hosts

 

[TheMrg]

if we update the microcode d owe have to reboot the hypervisor (proxox host) and/or any VM?
or it is enough to run
echo 1 > /sys/devices/system/cpu/microcode/reload on proxmox hypervisor?

 

[fabian]

doesn't work, since that path does not exist (late loading is disabled for a reason: https://docs.kernel.org/arch/x86/microcode.html#why-is-late-loading-dangerous). so yes, a reboot is needed after an update for it to take effect. you can check the version in /sys/device/systems/cpu/cpuX/microcode/version

 

[TheMrg]

ok , thanks.
what are the steps for?
there is no amd64-microcode
and n apt install amd64-microcode

btw: we have the path /sys/devices/system/cpu/microcode/reload using Proxmox 7.1

 

[fabian]

ok , thanks.
what are the steps for?
there is no amd64-microcode
and n apt install amd64-microcode

you need to enable a repository shipping that package - in this case, the Debian security one for Bookworm (or Bullseye, if you are on PVE 7.x).

btw: we have the path /sys/devices/system/cpu/microcode/reload using Proxmox 7.1

it was only disabled by default in kernel 5.19

 

[harmonyp]

doesn't work, since that path does not exist (late loading is disabled for a reason: https://docs.kernel.org/arch/x86/microcode.html#why-is-late-loading-dangerous). so yes, a reboot is needed after an update for it to take effect. you can check the version in /sys/device/systems/cpu/cpuX/microcode/version

Reboot the VMs + node or only node?

VMs still show old code with live migration

 

[fabian]

the VM is not responsible for loading microcode..

 

[TheMrg]

you need to enable a repository shipping that package - in this case, the Debian security one for Bookworm (or Bullseye, if you are on PVE 7.x)

thanks but:
Ok, so microcode updates NEVER done by proxmox by default? so older microcode updates were not installed, although we have reboot the host?

"it was only disabled by default in kernel 5.19"

Ok we have Linux version 5.13.19, so " /sys/devices/system/cpu/microcode/reload" would work?

many thanks.

 

[fabian]

thanks but:
Ok, so microcode updates NEVER done by proxmox by default? so older microcode updates were not installed, although we have reboot the host?

microcode updates come in via two ways:
- BIOS/UEFI updates by your mainboard vendor
- amd64-microcode/intel-microcode package, loaded by the kernel during early boot

if you haven't installed the microcode package, you don't get any updates, but the version provided by your mainboard.

"it was only disabled by default in kernel 5.19"

Ok we have Linux version 5.13.19, so " /sys/devices/system/cpu/microcode/reload" would work?

many thanks.

see the link in my previous reply - late loading is dangerous even if the option is available, rebooting is the way to go.

 

[ArnaudN]

Hi all,

Until BIOS updates are released and/or AMD releases the new microcode for all other affected CPU models.

Is the workaround persistent ?

modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

If "yes", then how do we revert it when we will have the new microcode available ?
If "no", what is the best approach to automatically apply the workaround ?

 

[TheMrg]

- amd64-microcode/intel-microcode package, loaded by the kernel during early boot

ok, to be claear, so with Proxmox "default" it is not enough to do "apt upgrade" and reboot the proxmox host.
we first have to install the amd64-microcode package?

 

[fabian]

yes. no microcode package, no microcode update.

but the most recent kernel packages (pve-kernel-5.15.108-1-pve in version 5.15.108-2 for PVE 7,
pve-kernel-6.2.16-5-pve in version 6.2.16-6 for PVE 8, both available in pve-no-subscription at the moment) contain the non-microcode fix as well, which covers both systems where no microcode update is available yet, or where an available update is not installed.

 

[donhwyo]

This brings up an old question. Do vm's need microcode installed or just the host?

Thanks

 

[aaron]

This brings up an old question. Do vm's need microcode installed or just the host?

Thanks

See:

the VM is not responsible for loading microcode..

 

[TheMrg]

we have
apt update
apt upgrade
and now:

Linux 5.13.19-6-pve #1 SMP PVE 5.13.19-15 (Tue, 29 Mar 2022 15:59:50 +0200)

PVE-Manager-Version pve-manager/7.4-16/0f39f621

seems old kernel 2022. Is there no newer?

 

[leesteken]

we have
apt update
apt upgrade
and now:

Linux 5.13.19-6-pve #1 SMP PVE 5.13.19-15 (Tue, 29 Mar 2022 15:59:50 +0200)

PVE-Manager-Version pve-manager/7.4-16/0f39f621

seems old kernel 2022. Is there no newer?

Please never run apt upgrade as that does not upgrade everything. Use the GUI or run apt dist-upgrade per the manual (and many remarks from the staff on this forum).

 

[fabian]

the 5.13 kernel does not get any further updates for quite a while already, 5.15 is the default kernel series for PVE 7.x

 

[TheMrg]

ok thanks.
do we have any problems with 5.13 Kernel? all VMs running fine.
we have microcode updated : microcode updated early to new patch_level=0x0830107a
so we can still be on kernel 5.13 or?

we do not like to reboot our proxmox again now. many customers

 

[fabian]

well, the main problem is that you don't get any security updates..

 

[TheMrg]

Thanks. Sure, but we have Kernelcare. This helps get some upgrades. we will upgrade the "dist" asap.